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

Hay dos principios básicos en juego aquí:

• Algunos códigos se ejecutan con mucha más frecuencia que otros códigos. Por ejemplo, es posible que nunca se use un código de manejo de errores. Algún código se ejecutará solo cuando inicies tu programa. El otro código se ejecutará una y otra vez mientras se ejecuta su programa.
• Algunos códigos demoran más en que otros códigos. Por ejemplo, una sola línea que ejecuta una consulta en una base de datos o extrae un archivo de Internet probablemente demore más. que millones de operaciones matemáticas.

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

Esta es una información importante, y significa que las decisiones que parecen contrarias a un nuevo desarrollador a menudo pueden ser correctas. Por ejemplo:

• Hay un montón de código que no vale la pena dedicar tiempo a hacer "mejor" , incluso si está haciendo las cosas de una manera simple y tonta. ¿Podrías 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 toma una cantidad de tiempo trivial, aunque hay miles de valores. Así que simplemente no vale la pena. Puede ser difícil para los nuevos desarrolladores evitar una optimización innecesaria, porque en su programa de estudios, 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 más largo y más complejo aún pueden ser un beneficio para el 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.

Esto no es una ley de la naturaleza, sino una regla empírica creada por una amplia experiencia. También se conoce como la regla 80/20, y solo es una aproximación aproximada.

Bucles, ramas y otros controles 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. Así se gasta 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 que DoWork(i) se producirá aproximadamente un millón de veces.

Bucles.

Estoy tentado a detenerme ahí! :-)

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 a su vez

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 (asumiendo que todas las líneas tardan aproximadamente el mismo tiempo en ejecutarse. Por lo tanto, el 40% del programa toma > 80%.

Con ejemplos más grandes 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 se suele decir, 80/20) es una "regla de oro": solo aproximadamente cierta.

Ver también Principio de Pareto

Como ha preguntado acerca del tiempo de ejecución solamente, 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 ser 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 10% restante del tiempo realiza un solo paso. cálculos.

Otro ejemplo es el manejo de errores en algunos servicios de alta disponibilidad. Cualquier servicio de alta disponibilidad está diseñado para funcionar infinito durante un período de tiempo normal. Normalmente funciona el 99% del tiempo, pero en ocasiones, en caso de error, ejecuta algún manejo y recuperación de errores, lo que puede ser incluso más complejo desde el punto de vista lógico 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 o OpenOffice :

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

Este dicho también se usa en ciencias de la administración ... Esta es una lección para la vida misma ... Significado: concentra la mayoría de tus esfuerzos donde te da 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 bucle for, ¿cuánto tiempo se gasta en este pedazo de código bastante pequeño? Bastante, mientras que 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 tomará.

Además del bucle, como lo mencionan otras grandes respuestas, también hay que tener en cuenta los principios DRY. Bien escrito, el código orientado a objetos tiene muchas partes reutilizables. Las partes que se reutilizan, por definición, se usan al menos dos veces más que algo que solo se ejecuta una vez. Si tiene un montón de código OO, podría estar reutilizando varias clases y métodos muchas veces, y algunas otras piezas de código solo una vez.

Como se mencionó en otras respuestas, probablemente sea mejor hacer un esfuerzo para que el código que se usa con más frecuencia sea mejor que mejorar el código que solo se usa una sola vez.

Eso no es una regla, es solo un tipo que editó Wikipedia con un par de números extraídos de la nada y lo llamó una regla. Compare 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 tu pregunta es que algunos códigos se ejecutan con mucha más frecuencia que otros códigos. 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 que "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 se vuelva a utilizar para la programación.

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

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

enlace