Quelle est la signification de la règle d’optimisation de programme 90/10?

Selon Wikipedia, la règle d'optimisation de programme 90/10 stipule que "90% du temps d'exécution d'un programme est consacré à l'exécution de 10% du code" (voir le deuxième paragraphe ici ).

Je ne comprends vraiment pas cela. Qu'est-ce que cela veut dire exactement? Comment peut-on consacrer 90% du temps d'exécution à l'exécution de 10% du code? Qu'en est-il des autres 90% du code alors? Comment peuvent-ils être exécutés dans seulement 10% du temps?

Il y a deux principes de base en jeu ici:

• Certains codes sont exécutés beaucoup plus souvent que d’autres. Par exemple, certains codes de traitement des erreurs peuvent ne jamais être utilisés. Certains codes seront exécutés uniquement lorsque vous démarrez votre programme. L'autre code sera exécuté à plusieurs reprises pendant l'exécution de votre programme.
• Certains codes prennent beaucoup plus de temps à exécuter que d'autres. Par exemple, une seule ligne qui exécute une requête sur une base de données ou extrait un fichier d'Internet prendra probablement plus de temps que des millions d'opérations mathématiques.

La règle 90/10 n'est pas littéralement vraie. Cela varie selon les programmes (et je doute que les chiffres 90 et 10 soient fondés; quelqu'un les a probablement tirés au hasard). Mais si vous voulez que votre programme soit plus rapide, seul un petit nombre de lignes est important pour y parvenir. Identifier les parties lentes de votre logiciel est souvent la partie la plus importante de l'optimisation.

Il s’agit là d’un élément important. Cela signifie que les décisions qui semblent contre-intuitives pour un nouveau développeur peuvent souvent être correctes. Par exemple:

• Il y a beaucoup de code pour lequel il ne vaut pas la peine que vous passiez à l'amélioration , même si vous faites les choses d'une manière simpliste et stupide. Pourriez-vous écrire un algorithme de recherche plus efficace pour l'application XYZ? Oui, mais en réalité, une simple comparaison de chaque valeur prend une quantité de temps triviale, même s'il existe des milliers de valeurs. Donc ça ne vaut tout simplement pas la peine. Il peut être difficile pour les nouveaux développeurs d'éviter une optimisation inutile, car leur programme d'études consacrait beaucoup de temps à l'écriture de l'algorithme "correct" (ce qui signifie le plus efficace). Mais dans le monde réel, le bon algorithme est celui qui fonctionne et fonctionne assez vite.
• Les modifications qui rendent votre code beaucoup plus long et plus complexe peuvent encore être gagnantes en performances. Par exemple, dans l’application FOO, il peut être utile d’ajouter des centaines de lignes de nouvelle logique, simplement pour éviter un seul appel à la base de données.

Ce n'est pas une loi de la nature, mais une règle empirique née d'une vaste expérience. Elle est également connue sous le nom de règle des 80/20 et n’est qu’une approximation approximative.

Boucles, branches et autres contrôles de flux.

Chaque lieu ayant un if, vous aurez une branche prise plus souvent que l’autre. Ainsi, une plus grande partie du temps d’exécution est consacrée à l’exécution de cette partie du programme et non de l’autre.

Chaque endroit qui a une boucle qui s'exécute plus d'une fois, vous avez un code qui est exécuté plus que le code environnant. Ainsi, on passe plus de temps là-bas.

À titre d'exemple, considérons:

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

Ici, la print("Oh No!")volonté ne fonctionnera jamais plus d'une fois, et souvent jamais, alors DoWork(i)qu'elle se produira environ un million de fois.

Boucles.

Je suis tenté de m'arrêter là! :-)

Considérez ce programme

1. do_something

2. loop 10 times
3.    do_another_thing

4.    loop 5 times
5.        do_more_stuff

La ligne 1 est exécutée une fois tandis que la ligne 3 est exécutée 10 fois. En regardant chaque ligne à tour de rôle

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

Deux lignes représentent 83% du temps d'exécution (en supposant que toutes les lignes prennent à peu près le même temps. Donc, 40% du programme prend> 80%.

Avec des exemples plus grands et plus réels, ce nombre augmente, de sorte que seule une petite quantité de lignes représente une grande partie de l'exécution.

La règle 90/10 (ou comme parfois 80/20) est une "règle empirique" - approximativement vraie.

Voir aussi le principe de Pareto

Comme vous avez posé des questions sur l'heure d'exécution uniquement, cet exemple peut être utile:

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;
}

Pour être un peu plus sérieux, cela signifie que dans le code réel, vous appelez presque toujours une fonction lourde dans une boucle (au lieu de sleep(90);), tandis que les 10% restants effectuent des calculs en une seule passe.

Un autre exemple est la gestion des erreurs dans certains services de haute disponibilité. Tout service hautement disponible est conçu pour fonctionner dans un temps infini dans des conditions normales. Il fonctionne normalement pendant 99% du temps, mais occasionnellement, en cas d'erreur, il exécute des opérations de traitement et de récupération des erreurs, qui peuvent être encore plus complexes logiquement que le service lui-même.

Le raisonnement 90/10 signifie qu'une petite partie de votre code sera répétée ou utilisée plus que d'autres. Ceci est souvent utilisé pour suggérer que vous devriez concentrer 90% de vos efforts de développement / optimisation dans ces 10% de votre code.

Pensez à un traitement de texte normal, comme Microsoft Word ou OpenOffice :

• La boîte de dialogue des préférences n’est pas très utilisée;
• Les sous-routines qui dessinent des caractères sont utilisées tout le temps.

Ce dicton est également utilisé dans les sciences de gestion ... Ceci est une leçon de la vie elle-même ... Sens: concentrez la plupart de vos efforts là où vous donne plus de résultats.

Imaginez un programme comme celui-ci:

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"

Remarquez comment il y a 11 lignes ici où 3 des 11 sont la boucle for, où combien de temps est consacré à ce morceau de code plutôt petit? Un peu, alors que les 8 autres lignes n’impriment qu’un seul caractère. Ainsi, sachez que, même si certains codes sont courts, ils ne vous disent pas à quelle fréquence il est exécuté ni combien de temps cela prend.

En plus des boucles, comme mentionné par d’autres bonnes réponses, il ya aussi des principes DRY à prendre en compte. Bien écrit, le code orienté objet comporte de nombreuses parties réutilisables. Les pièces réutilisées, par définition, sont utilisées au moins deux fois plus souvent qu’une chose exécutée une seule fois. Si vous avez beaucoup de code OO, vous pourriez potentiellement réutiliser plusieurs classes et méthodes plusieurs fois, et quelques autres morceaux de code une seule fois.

Comme mentionné dans d'autres réponses, il est probablement préférable de consacrer plus d'efforts à l'amélioration du code utilisé plus souvent qu'à l'amélioration du code utilisé une seule fois.

Ce n'est pas une règle, c'est juste un type qui a édité Wikipédia avec quelques chiffres tirés de nulle part et appelé cela une règle. Comparez avec le principe de Pareto, qui est plus fermement établi dans d'autres contextes. J'aimerais voir quelles recherches ont été effectuées (le cas échéant) sur l'exactitude de cette "règle".

Mais fondamentalement, la réponse à votre question est que certains codes sont exécutés beaucoup plus souvent que d’autres. Les boucles en sont souvent la raison. D'autres raisons sont des appels chronophages, par exemple vers des ressources externes telles que des services Web ou des supports de stockage.

Il s'agit d'une réinterprétation du "principe de Pareto", selon lequel "pour de nombreux événements, environ 80% des effets proviennent de 20% des causes", également appelée règle des 80/20. Cette règle s’appliquant principalement à l’économie, il est donc logique qu’elle soit utilisée à des fins de programmation.

C'est simplement une tendance qui a été observée sur une longue période.

Voici une très belle vidéo sur de tels modèles, qui explique également le principe de Pareto.

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