¿Cuál es el significado de la regla 90/10 de optimización de programas?

Según Wikipedia, la regla 90/10 de optimización de programas establece que "el 90% del tiempo de ejecución de un programa se gasta en la ejecución del 10% del código" (vea el segundo párrafo aquí ).

Realmente no entiendo esto. ¿Qué significa esto exactamente? ¿Cómo puede gastarse el 90% del tiempo de ejecución solo ejecutando el 10% del código? ¿Qué pasa con el otro 90% del código entonces? ¿Cómo se pueden ejecutar en solo el 10% del tiempo?

Aquí hay dos principios básicos en juego:

• Algunos códigos se ejecutan con mucha más frecuencia que otros. Por ejemplo, es posible que algún código de manejo de errores nunca se use. Algunos códigos se ejecutarán solo cuando inicie su programa. Otro código se ejecutará una y otra vez mientras se ejecuta su programa.
• Algunos códigos tardan mucho más en ejecutarse que otros. Por ejemplo, una sola línea que ejecuta una consulta en una base de datos o extrae un archivo de Internet probablemente llevará más tiempo que millones de operaciones matemáticas.

La regla 90/10 no es literalmente cierta. Varía según el programa (y dudo que haya alguna base para los números específicos 90 y 10; alguien probablemente los sacó de la nada). Pero el punto es que si necesita que su programa se ejecute más rápido, probablemente solo un pequeño número de líneas es importante para que eso suceda. Identificar las partes lentas de su software es a menudo la mayor parte de la optimización.

Esta es una idea importante, y significa que las decisiones que parecen contradictorias para un nuevo desarrollador a menudo pueden ser correctas. Por ejemplo:

• Hay un montón de código que no vale la pena hacer "mejor" , incluso si está haciendo las cosas de una manera tonta y simplista. ¿Podría escribir un algoritmo de búsqueda más eficiente para la aplicación XYZ? Sí, pero en realidad una comparación simple de cada valor lleva una cantidad de tiempo trivial, a pesar de que hay miles de valores. Entonces no vale la pena. Puede ser difícil para los nuevos desarrolladores evitar una optimización innecesaria, porque en su programa de grado se dedicó mucho tiempo a escribir el algoritmo "correcto" (es decir, el más eficiente). Pero en el mundo real, el algoritmo correcto es cualquiera que funcione y funcione lo suficientemente rápido.
• Los cambios que hacen que su código sea mucho más largo y complejo aún pueden ser una ganancia de rendimiento. Por ejemplo, en la aplicación FOO puede valer la pena agregar cientos de líneas de nueva lógica, solo para evitar una sola llamada a la base de datos.

Esta no es una ley de la naturaleza, sino una regla general nacida de una amplia experiencia. También se conoce como la regla 80/20, y solo es una aproximación aproximada.

Bucles, ramas y otro control de flujo.

Cada lugar que tenga un if, tendrá una rama que se toma con más frecuencia que la otra rama. Por lo tanto, se pasa más tiempo de ejecución ejecutando esa parte del programa, y ​​no la otra parte.

Cada lugar que tiene un bucle que se ejecuta más de una vez, tiene un código que se ejecuta más que el código circundante. Por lo tanto, se pasa más tiempo allí.

Como ejemplo, considere:

def DoSomeWork():
    for i in range(1000000):
        DoWork(i)
    except WorkExeption:
        print("Oh No!")

Aquí print("Oh No!")solo se ejecutará un máximo de una vez, y a menudo nunca, mientras DoWork(i)que ocurrirá aproximadamente un millón de veces.

Bucles.

Estoy tentado de parar allí! :-)

Considera este programa

1. do_something

2. loop 10 times
3.    do_another_thing

4.    loop 5 times
5.        do_more_stuff

La línea 1 se ejecuta una vez, mientras que la línea 3 se ejecuta 10 veces. Mirando cada línea por turno

1 1   0.8%
2 10  8.3%
3 10  8.3%
4 50 41.3%
5 50 41.3%

Dos líneas representan el 83% del tiempo de ejecución (suponiendo que todas las líneas tarden aproximadamente el mismo tiempo en ejecutarse. Por lo tanto, el 40% del programa toma> 80%.

Con ejemplos más grandes y del mundo real, esto aumenta, por lo que solo una pequeña cantidad de líneas representa gran parte del tiempo de ejecución.

La regla 90/10 (o como a veces se pone 80/20) es una "regla de oro", solo aproximadamente cierta.

Ver también Principio de Pareto

Como preguntó solo sobre el tiempo de ejecución, este ejemplo podría ser útil:

int main() {
    sleep(90); // approximately 10% of the program.
    // other 90% of the program:
    sleep(1);
    sleep(1);
    sleep(1);
    sleep(1);
    sleep(1);
    sleep(1);
    sleep(1);
    sleep(1);
    sleep(1);
    sleep(1);
    return 0;
}

Si es un poco más serio, significa que en el código de la vida real casi siempre se llama una función pesada en un bucle (en lugar de sleep(90);), mientras que el resto del 10% del tiempo realiza algunos cálculos de un solo paso.

Otro ejemplo es el manejo de errores en algunos servicios de alta disponibilidad. Cualquier servicio de alta disponibilidad está diseñado para trabajar una cantidad de tiempo infinita en condiciones normales. Funciona normalmente el 99% del tiempo, pero ocasionalmente, en caso de error, ejecuta un manejo y recuperación de errores, que puede ser aún más lógicamente complejo que el servicio en sí.

El razonamiento 90/10 significa que una pequeña parte de su código se repetirá o usará más que otros. Esto se usa a menudo para sugerir que debe concentrar el 90% de su esfuerzo de desarrollo / optimización en este 10% de su código.

Piense en un procesador de texto normal, como Microsoft Word u OpenOffice :

• El diálogo de preferencias, no se usa mucho;
• Las subrutinas que dibujan caracteres se usan todo el tiempo.

Este dicho también se usa en las ciencias de gestión ... Esta es una lección para la vida misma ... Significado: concentra la mayor parte de tus esfuerzos donde obtengas más resultados.

Imagina un programa como este:

print "H"
print "e"
print "l"
print "l"
print "o"
for i=0 to 1,000,000
    print "How long now?"
next
print "B"
print "y"
print "e"

Observe cómo hay 11 líneas aquí, donde 3 de las 11 son el ciclo for, ¿cuánto tiempo se dedica a este pequeño código? Bastante mientras las otras 8 líneas simplemente imprimen un solo carácter. Por lo tanto, tenga en cuenta que si bien algunos códigos pueden ser cortos, eso no le dice con qué frecuencia se ejecuta y cuánto tiempo llevará.

Además del bucle, como lo mencionan otras excelentes respuestas, también hay que considerar los principios DRY. Bien escrito, el código orientado a objetos tiene muchas partes reutilizables. Esas partes que se reutilizan, por definición, se usan al menos el doble de veces que algo que solo se ejecuta una vez. Si tiene una gran cantidad de código OO, podría estar reutilizando algunas clases y métodos muchas veces, y algunas otras piezas de código solo una vez.

Como se menciona en otras respuestas, probablemente sea mejor gastar esfuerzo haciendo que el código que se usa con más frecuencia sea mejor que mejorar el código que solo se usa una vez.

Esa no es una regla, es solo un tipo que editó Wikipedia con un par de números sacados de la nada y lo calificó como una regla. Compárese con el Principio de Pareto, que está más firmemente establecido en otros contextos. Me gustaría ver qué investigaciones se han realizado (si las hay) sobre la precisión de esta "regla".

Pero, básicamente, la respuesta a su pregunta es que algunos códigos se ejecutan con mucha más frecuencia que otros. Los bucles son a menudo la razón de esto. Otras razones son llamadas que requieren mucho tiempo, por ejemplo, a recursos externos como servicios web o medios de almacenamiento.

Es una reinterpretación del "principio de Pareto", que establece "para muchos eventos, aproximadamente el 80% de los efectos provienen del 20% de las causas", también conocida como la regla 80/20. Esta regla se aplica principalmente a la economía, por lo que tiene sentido que sea destinada a la programación.

Es solo un patrón que se ha observado durante un largo período de tiempo.

Aquí hay un video muy agradable sobre patrones como este, y también explica el Principio de Pareto.

https://www.youtube.com/watch?v=fCn8zs912OE&ab_channel=Vsauce