Post actualizado el día octubre 29, 2026 by DeiviSanzPlay
Hay un detalle que casi nadie menciona cuando se estudia un algoritmo de complejidad computacional: la notación O grande describe cómo crece el tiempo de ejecución cuando n tiende a infinito, no cuánto tarda tu programa en el portátil de tu oficina. Ese desfase es la raíz de muchos errores de decisión técnica.
La pregunta puntual es esta: ¿por qué un algoritmo con mejor complejidad asintótica a veces rinde peor que uno con peor complejidad? La respuesta exacta tiene nombre: constantes ocultas y tamaño real del problema.
El caso del ordenamiento híbrido
Imagina que tienes que ordenar listas de 30 elementos dentro de un bucle que se ejecuta miles de veces. Un merge sort tiene complejidad O(n log n) y un insertion sort O(n²). En el papel, el primero gana siempre. En la práctica, para n pequeño, el insertion sort arrasa porque tiene menos sobrecarga por elemento y mejor localidad de caché.
Por eso los algoritmos de ordenamiento reales —TimSort en Python o Java, introsort en la STL de C++— son híbridos: usan inserción para sublistas cortas y cambian a quicksort o merge cuando el tamaño crece. Esa decisión no sale del análisis asintótico puro, sale de medir.
La complejidad computacional de un algoritmo te dice la tendencia, no el cronómetro. Confundir ambas cosas es el error más común que veo en revisiones de código.
Constantes que rompen la teoría
Un algoritmo O(n) con un factor constante de 200 puede ser más lento que un O(n log n) con factor de 1 hasta valores de n bastante altos. Piensa en recorrer un array en memoria (operación de nanosegundos) frente a recorrer una lista enlazada con saltos de puntero (fallos de caché). Los dos son lineales, pero uno es decenas de veces más rápido en la práctica.
Esto no invalida el análisis de complejidad computacional: lo contextualiza. Para volúmenes pequeños o medianos, el hardware manda. Para volúmenes que crecen sin control, la asíntota manda.
Mi regla: si n < 1000 y el algoritmo corre pocas veces, no te obsesiones con la notación. Si n es un parámetro de entrada que puede crecer, ahí sí.
El problema puntual: elegir entre dos soluciones
Supón que necesitas detectar duplicados en una colección. Opción A: dos bucles anidados, O(n²), sin memoria extra. Opción B: una tabla hash, O(n) promedio, con memoria adicional proporcional a n.
Con 500 elementos, la opción A tarda milisegundos y no consume RAM extra. Con 5 millones, la opción A es inviable. La solución exacta no es «usa hash siempre» ni «evita hash por memoria»: es medir con el tamaño real esperado y el presupuesto de memoria disponible.
Y ojo con un matiz que se ignora: el O(n) de la tabla hash es promedio. Con malas funciones hash o colisiones masivas, puede degradarse a O(n²). Ningún análisis de complejidad computacional serio obvia el peor caso.
Dónde el análisis asintótico no sirve
Hay escenarios donde calcular la complejidad computacional del algoritmo apenas aporta:
—Tamaños fijos y pequeños: si n nunca pasa de 50, la asíntota es irrelevante.
—Cuellos de botella externos: si tu algoritmo espera a una base de datos o a la red, la complejidad del código es ruido frente a la latencia de I/O.
—Entradas adversarias: un hash map puede comportarse como una lista si el atacante controla las claves. Este es un problema real en servicios expuestos a internet.
—Paralelización: dos algoritmos O(n) pueden tener rendimiento completamente distinto en GPU según su patrón de acceso a memoria.
Esto no funciona para decidir arquitecturas de sistemas distribuidos ni para comparar lenguajes interpretados con compilados. La notación asintótica compara algoritmos sobre el mismo modelo de máquina, no máquinas distintas.
Medir antes de teorizar
La complejidad algorítmica se enseña con pizarras, pero se aplica con cronómetros. Un benchmark con tamaños reales de entrada (100, 1.000, 10.000, 100.000) muestra en minutos si la curva teórica se cumple o si las constantes dominan.
He visto equipos reescribir funciones perfectamente válidas porque «tenían O(n²)» cuando esa función se llamaba tres veces al arrancar el servidor. Optimización inútil. Y he visto lo contrario: pasar por alto un bucle anidado dentro de una consulta que se ejecutaba por cada usuario.
El algoritmo de complejidad computacional es una brújula, no un GPS. Te orienta sobre qué dirección escala, pero el camino concreto depende de tus datos, tu hardware y tu presupuesto. Quien te venda una respuesta única sin medir, te está vendiendo teoría mal aplicada.
Perfiles verificables: Sitio web
Publicado el 29 de October de 2026. Última revisión: 29 de October de 2026.
