Post actualizado el día octubre 29, 2026 by DeiviSanzPlay
Cuando alguien busca algoritmo Big O notación en Google casi nunca quiere la definición de manual. Quiere resolver una duda concreta que le corroe: si mi bucle recorre dos veces el array, ¿es O(2n) o ya es O(n)? Y la respuesta corta, la que casi nadie da de forma directa, es que O(2n) y O(n) son la misma clase de complejidad. La notación Big O no mide operaciones exactas, mide cómo crece el tiempo o el espacio cuando la entrada tiende a infinito, y las constantes se descartan por definición formal.
Esa es la primera trampa en la que cae casi todo el mundo que empieza. Yo también caí. Recuerdo un script de análisis de logs donde contaba cada iteración para «demostrar» que mi solución era más rápida que la de un compañero porque hacía menos pasadas. El benchmark real, con ficheros de tamaño creciente, mostró diferencias que se diluían a medida que el dataset crecía. La lección: el algoritmo Big O notación no sirve para microoptimizar; sirve para predecir qué aguanta cuando los datos se multiplican.
Qué mide realmente la notación asintótica
Big O describe una cota superior del crecimiento. Cuando dices que una función es O(n²), estás afirmando que existe una constante y un punto a partir del cual el tiempo de ejecución nunca supera a esa constante multiplicada por n². No estás diciendo cuántos milisegundos tarda, ni cuántas comparaciones hace, ni si usa más o menos memoria. Solo la forma de la curva.
Por eso el algoritmo Big O notación ignora factores como el coste de acceso a caché, la velocidad del compilador o si el lenguaje gestiona memoria automáticamente. Un O(n) en Python puede ser más lento que un O(n log n) en C para entradas pequeñas. La notación no promete velocidad, promete comportamiento a gran escala.
Existe además la variante Big Omega (cota inferior) y Big Theta (cota ajustada). Mucha gente las mezcla y escribe O cuando en realidad quiere decir Θ. En entrevistas técnicas se acepta la imprecisión; en papers y análisis formal, no.
El error de contar constantes: mi caso con dos bucles
Supongamos una función que primero recorre una lista para filtrar elementos y luego la vuelve a recorrer para transformarlos. Dos bucles secuenciales, cada uno de longitud n. El total de operaciones es aproximadamente 2n más lo que cueste cada operación interna. La tentación es escribir O(2n). La respuesta correcta es O(n).
El motivo: la definición de notación asintótica permite absorber cualquier constante multiplicativa dentro de la constante de la cota. Si 2n cabe dentro de c·n para c=2, entonces 2n pertenece a O(n). Y si mañana el código necesita cuatro pasadas, seguirá siendo O(n). Lo que cambiará es el tiempo real, no la clase de complejidad.
Esto tiene una consecuencia práctica incómoda: cuando comparas dos soluciones y ambas son O(n), el algoritmo Big O notación ya no te ayuda a elegir. Ahí entran los benchmarks, el perfilado y el contexto de uso. La notación te dice si el diseño escala; no te dice cuál es más rápido en tu máquina concreta.
Casos donde Big O se queda corto
Hay escenarios donde la notación asintótica no funciona bien como criterio de decisión. El primero: entradas pequeñas. Para n menor que cierto umbral, un algoritmo O(n²) con constante baja puede batir a un O(n log n) con constante alta. Los algoritmos de ordenación híbridos como Timsort lo aprovechan y cambian de estrategia según el tamaño del subarray.
El segundo: restricciones de memoria. Un algoritmo O(n) en tiempo puede requerir O(n) de espacio adicional, y eso en un entorno embebido es inviable. La notación Big O notación de espacio existe, pero rara vez se analiza con el mismo rigor que la temporal.
El tercero: operaciones con coste oculto. Acceder a un elemento de un array es O(1) en teoría, pero si ese array no cabe en caché cada acceso puede costar decenas de ciclos. Un recorrido lineal sobre memoria dispersa puede ser más lento que un recorrido cuadrático sobre datos contiguos. La notación no ve esa diferencia.
Cómo usarla sin engañarte a ti mismo
Mi recomendación tras años rompiendo código: usa Big O para descartar diseños que no escalan, no para elegir el ganador. Si una solución es O(2ⁿ) y otra O(n log n), no hay debate. Si ambas son O(n) o O(n log n), mide.
Cuando estimes complejidad, identifica primero el bucle dominante y pregúntate qué variable crece. Un error clásico es asumir que todo bucle anidado es O(n²) cuando en realidad los índices son independientes (por ejemplo, recorrer una matriz n×m es O(n·m), no O(n²) si n≠m). Otro error habitual: olvidar que las operaciones sobre strings en lenguajes inmutables (como Java o Python) pueden ser O(k) por concatenación, donde k es la longitud acumulada, lo que convierte un bucle aparentemente lineal en cuadrático.
El algoritmo Big O notación sigue siendo la herramienta más útil que conozco para pensar en rendimiento a gran escala, pero es una lente, no un veredicto. Aprender a leerla con matices, y sobre todo a saber cuándo dejar de mirarla, marca más diferencia que memorizar la tabla de complejidades.
Perfiles verificables: Sitio web
Publicado el 29 de October de 2026. Última revisión: 29 de October de 2026.
