web-dev-qa-db-fra.com

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

Selon Wikipedia, la règle 90/10 de l'optimisation des programmes 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 signifie exactement? Comment peut-on passer 90% du temps d'exécution à exécuter seulement 10% du code? Qu'en est-il alors des 90% restants du code? Comment peuvent-ils être exécutés en seulement 10% du temps?

optimizationtheoryprogram
67
Rakshith Ravi

Il y a deux principes de base en jeu ici:

  • Certains codes sont exécutés beaucoup plus souvent que d'autres codes. Par exemple, certains codes de gestion des erreurs peuvent ne jamais être utilisés. Certains codes ne seront exécutés qu'au démarrage de votre programme. D'autres codes seront exécutés encore et encore pendant l'exécution de votre programme.
  • Certains codes prennent beaucoup plus longtemps à exécuter que les autres codes. Par exemple, une seule ligne qui exécute une requête sur une base de données, ou extraire 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 le programme (et je doute qu'il y ait une base pour les nombres spécifiques 90 et 10; quelqu'un les a probablement tirés de nulle part). Mais le fait est, si vous avez besoin que votre programme s'exécute plus rapidement, seul un petit nombre de lignes est probablement important pour que cela se produise. L'identification des parties lentes de votre logiciel est souvent la plus grande partie de l'optimisation.

Il s'agit d'un aperçu important, et 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 qui ne vaut pas la peine de faire du "mieux", même s'il fait les choses d'une manière stupide et simpliste. Pourriez-vous écrire un algorithme de recherche plus efficace pour l'application XYZ? Oui, mais en fait, une simple comparaison de chaque valeur prend un temps insignifiant, même s'il existe des milliers de valeurs. Donc ça n'en vaut pas la peine. Il peut être difficile pour les nouveaux développeurs d'éviter une optimisation inutile, car dans leur programme d'études, beaucoup de temps a été consacré à l'écriture de l'algorithme "correct" (ce qui signifie le plus efficace). Mais dans le monde réel, l'algorithme correct est celui qui fonctionne et s'exécute assez rapidement.
  • Les modifications qui rendent votre code beaucoup plus long et plus complexe peuvent toujours être un gain de performances. Par exemple, dans l'application FOO, il peut être utile d'ajouter des centaines de lignes de nouvelle logique, juste pour éviter un seul appel à la base de données.
183
user82096

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

Boucles, branches et autre contrôle de flux.

Chaque endroit qui a un if, vous aurez une branche qui est prise plus souvent que l'autre branche. 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 partie.

Chaque endroit qui a une boucle qui s'exécute plus d'une fois, vous avez du code qui est exécuté plus que le code environnant. On y passe donc plus de temps.

À titre d'exemple, considérons:

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

Ici, la print("Oh No!") ne s'exécutera jamais qu'un maximum, et souvent jamais, tandis que la DoWork(i) se produira environ un million de fois.

20
Caleth

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 à tour

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 environ le même temps pour s'exécuter. Donc, 40% du programme prend> 80%.

Avec des exemples plus grands et plus réels, cela 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 on l'appelle parfois 80/20) est une "règle d'or" - seulement approximativement vraie.

Voir aussi le principe de Pareto

16
Nick Keighley

Comme vous ne l'avez demandé que pour le temps d'exécution, 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;
}

Si pour être un peu plus sérieux, cela signifie que dans le code de la vie réelle, vous appelez presque toujours une fonction lourde dans une boucle (au lieu de sleep(90);), tandis que le reste 10% du temps, vous effectuez une seule passer des calculs.

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

5
Sergey

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 votre effort de développement/optimisation dans ces 10% de votre code.

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

  • La boîte de dialogue des préférences, n'est pas beaucoup utilisée;
  • Les sous-programmes qui dessinent les caractères sont utilisés tout le temps.

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

3
Lucas

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 sur les 11 sont la boucle for, où combien de temps est passé sur ce morceau de code plutôt petit? Un peu, alors que les 8 autres lignes ne font qu'imprimer un seul caractère. Ainsi, sachez que même si certains codes peuvent être courts, cela ne vous dit pas à quelle fréquence il est exécuté et combien de temps cela prendra.

2
JB King

C'est une réinterprétation du "principe de Pareto", qui stipule "pour de nombreux événements, environ 80% des effets proviennent de 20% des causes", également connu sous le nom de règle 80/20. Cette règle est principalement appliquée à l'économie, il est donc logique qu'elle soit réutilisée pour la programmation.

C'est juste un schéma qui a été observé sur une longue période de temps.

Voici une très belle vidéo sur des modèles comme celui-ci, et elle explique également le principe de Pareto.

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

0
imnota4

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 l'a appelé 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é faites (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 fréquemment que d'autres codes. Les boucles en sont souvent la raison. Les autres raisons sont les appels qui prennent du temps, par exemple aux ressources externes comme les services Web ou les supports de stockage.

0
Brad Thomas

En plus du bouclage, comme mentionné par d'autres bonnes réponses, il y a aussi DRY principes à considérer. Bien écrit, le code orienté objet a beaucoup de parties réutilisables. Ces parties qui sont réutilisées, par définition, être utilisé au moins deux fois plus souvent que quelque chose qui n'est exécuté qu'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 à rendre le code utilisé plus souvent que d'améliorer le code qui n'est utilisé qu'une seule fois.

0
Marshall Tigerus