Post actualizado el día octubre 29, 2026 by DeiviSanzPlay
Cuando alguien aprende algoritmo Big O notación, casi siempre se queda con la parte bonita: contar bucles y decir que O(n) es mejor que O(n²). El problema aparece después, cuando ese mismo código tarda el triple en el servidor real y nadie entiende por qué. La notación Big O describe cómo crece el coste de un algoritmo cuando la entrada crece, no cuánto tarda en tu portátil.
Esa distinción es la que explica la mayoría de las sorpresas. Big O no mide segundos, mide tendencia. Y la tendencia cambia de forma brutal cuando los datos reales superan el tamaño de los que usaste en tus pruebas.
El error clásico: confundir Big O con un cronómetro
Vi esto hace poco en un proyecto de logística. Una función que buscaba un pedido dentro de una lista de resultados funcionaba en milisegundos con cien registros de prueba. En producción, con la base de datos creciendo, el listado se volvió lentísimo. El algoritmo era correcto, pero su complejidad temporal era lineal respecto al número de pedidos, y se ejecutaba una vez por cada fila mostrada. Lineal dentro de lineal: cuadrático disfrazado.
La notación asintótica no te avisa de eso si solo miras la función aislada. Hay que mirar el contexto de llamada. Un O(n) dentro de un bucle O(n) se convierte en O(n²) aunque cada pieza parezca inocente.
Por qué O(log n) no siempre es la respuesta
La búsqueda binaria es el ejemplo estrella de la complejidad logarítmica. Se repite tanto en los cursos que parece una verdad universal: si puedes ordenar y aplicar búsqueda binaria, mejora. Pero hay un matiz que casi nadie menciona en las explicaciones básicas: ordenar también cuesta. Si solo vas a hacer una búsqueda sobre datos desordenados, ordenar primero puede salir más caro que recorrer la lista una vez.
El algoritmo Big O notación sirve aquí para hacer la cuenta honesta: O(n log n) por ordenar más O(log n) por buscar frente a O(n) por recorrer. Con una sola consulta, el recorrido lineal gana. Con muchas consultas repetidas sobre el mismo conjunto, el ordenamiento se amortiza. Esa decisión es de diseño, no de notación.
El caso de las estructuras de datos que rompen la teoría
Decir que un acceso a un diccionario o a una tabla hash es O(1) es una simplificación útil, pero incompleta. En el peor caso, con colisiones mal gestionadas, el acceso puede degradarse hacia un comportamiento lineal. En la práctica, las implementaciones modernas lo controlan, aunque no hay garantía absoluta.
Esto importa cuando diseñas sistemas con claves predecibles o con funciones hash pobres. La notación Big O te da la tendencia esperada, no un contrato blindado. Aquí la experiencia pesa más que la teoría: he visto tablas hash con más colisiones de las razonables por usar claves que compartían prefijo y una función hash ingenua.
Complejidad espacial: la mitad que casi nadie calcula
La mayoría de tutoriales se centran en el tiempo y dejan de lado la memoria. La notación de complejidad algorítmica también describe el espacio. Un algoritmo recursivo elegante puede consumir O(n) de pila de llamadas y reventar con entradas grandes. Pasa en funciones recursivas que procesan árboles profundos o listas largas.
En un servicio web con miles de peticiones concurrentes, un algoritmo O(n) en espacio puede ser más peligroso que uno O(n²) en tiempo, porque tumba el proceso en lugar de hacerlo lento. La memoria no perdona igual que la CPU.
Cuándo el análisis Big O no ayuda
Hay escenarios donde la notación asintótica aporta poco. Por ejemplo, con entradas pequeñas y constantes: si tu algoritmo siempre procesa diez elementos, la diferencia entre O(n²) y O(n) es irrelevante en la práctica. Los factores constantes dominan. También pasa en código con operaciones de entrada/salida intensivas, donde el coste real lo marca el disco o la red, no la estructura del bucle.
Otro límite: Big O describe el comportamiento asintótico, no el rendimiento en hardware concreto. Un algoritmo con peor complejidad puede ser más rápido en la práctica si sus operaciones son más baratas en caché. Los microprocesadores modernos tienen jerarquías de memoria que alteran mucho las cuentas teóricas.
Cómo usar esta notación sin volverte loco
Mi recomendación es tratar la notación Big O como una brújula, no como un GPS. Te indica la dirección del crecimiento, no la ruta exacta. Úsala para detectar patrones peligrosos: bucles anidados sobre colecciones grandes, recursión sin caso base bien acotado, búsquedas lineales dentro de bucles, estructuras que se recorren varias veces sin necesidad.
Después, mide. Un perfilado real con datos representativos te dirá si esa mejora teórica impacta en tu caso. La documentación clásica sobre análisis de algoritmos, como la que aparece en los libros de referencia de Cormen o Sedgewick, insiste en la misma idea: la notación es una herramienta de comparación, no una promesa de velocidad.
El algoritmo Big O notación sigue siendo el mejor lenguaje para hablar de escalabilidad sin pelearse con números concretos. Pero conviene recordar que un código con buena complejidad puede seguir siendo lento por mil razones: una consulta mal indexada, una serialización innecesaria, un lock mal colocado. La notación no cubre todo, y quien lo olvida acaba optimizando lo que no toca.
Perfiles verificables: Sitio web
Publicado el 29 de October de 2026. Última revisión: 29 de October de 2026.
