Quand l'optimisation est-elle prématurée?

Question

Comme Knuth a dit,

On devrait oublier les petites efficacité, disons environ 97% de l'optimisation prématurée est la racine de tous les maux.

C'est quelque chose qui revient souvent dans le Débordement de la Pile réponses à des questions comme "qui est le plus efficace mécanisme de boucle", "SQL techniques d'optimisation?" (et ainsi de suite). La réponse à ces optimisation, conseils questions est le profil de votre code et de voir si c'est un premier problème, et si il n'a pas, par conséquent, votre nouvelle technique est inutile.

Ma question est, si une technique est différente, mais pas particulièrement obscur ou occulté, peut vraiment être considéré comme un prématuré optimisation?

Voici un article connexe par Randall Hyde appelle Le Sophisme de l'Optimisation Prématurée.

Answer 1

Don Knuth a commencé le lettré de la programmation du mouvement parce qu'il croyait que la fonction la plus importante de code informatique est de communiquer le programmeur de l'intention d'un lecteur humain. Toute pratique de codage qui rend votre code plus difficile à comprendre au nom de la performance est une optimisation prématurée.

Certains idiomes qui ont été introduites dans le nom de l'optimisation sont devenus si populaires que tout le monde les comprend , et ils sont devenus prévu, pas prématuré. Les exemples incluent

• En utilisant l'arithmétique des pointeurs au lieu de la notation de tableau en C, y compris l'utilisation de telles expressions idiomatiques comme

  for (p = q; p < lim; p++)
  

• Reliaison des variables globales pour les variables locales en Lua, comme dans

  local table, io, string, math
      = table, io, string, math
  

Au-delà de ces idiomes, de prendre des raccourcis à vos risques et périls.

Tout d'optimisation est prématuré, à moins que

• Un programme est trop lent (beaucoup de gens oublient cette partie).

• Vous avez une mesure (profil ou similaire), montrant que l'optimisation peut améliorer les choses.

(Il est également permis d'optimiser la mémoire.)

Réponse directe à la question:

• Si votre "différentes" la technique rend le programme plus difficile à comprendre, alors c'est une optimisation prématurée.

---

EDIT: En réponse aux commentaires, à l'aide de quicksort au lieu d'un simple algorithme comme le tri par insertion est un autre exemple d' un langage que tout le monde comprenne et s'attend. (Bien que si vous écrivez votre propre routine de tri au lieu d'utiliser la bibliothèque de la routine de tri, on espère que vous avez une très bonne raison.)

Answer 2

À mon humble avis, 90% de votre optimisation devrait se produire au stade de la conception, basée sur la supposée actuelle, et plus important encore, les besoins futurs. Si vous avez à prendre d'un profiler parce que votre application n'est pas à l'échelle de la charge que vous avez laissé trop tard, et de l'OMI allez perdre beaucoup de temps et d'efforts tout en omettant de corriger le problème.

Les seules optimisations qui sont dignes d'intérêt sont ceux que le gain d'un ordre de grandeur d'amélioration de la performance en termes de vitesse, ou un multiplicateur dans les conditions de stockage ou de bande passante. Ces types d'optimisations ont généralement trait à la sélection d'un algorithme et de la stratégie de stockage, et sont extrêmement difficiles à inverser dans le code existant. Ils peuvent aller aussi profond que d'influencer la décision de la langue dans laquelle vous mettez en œuvre votre système.

Donc, mon conseil, optimiser tôt, en fonction de vos besoins, pas votre code, et d'envisager l'éventuelle durée de vie prolongée de votre application.

Answer 3

Si vous n'avez pas profilé, c'est prématuré.

Answer 4

Ma question est, si un particulier la technique est différente, mais pas particulièrement obscur ou occulté, peut vraiment être considéré comme un prématuré d'optimisation?

Euh... vous avez Donc deux techniques à portée de main, identiques en termes de coût (même effort à utiliser, lire, modifier) et on est plus efficace. Non, l'utilisation la plus efficace ne serait pas, dans ce cas, être prématuré.

Interrompre votre code écrit à chercher des alternatives à la programmation courante / routines de la bibliothèque sur la chance qu'il y a une version efficace traîner quelque part, même si pour tout vous savez que la vitesse relative de ce que vous écrivez ne sera jamais réellement question... C'est prématuré.

Answer 5

Quels vous semblent être en train de parler d'optimisation de l'utilisation d'une base de hachage de recherche contenant vs indexé un comme un tableau quand il y a beaucoup de clés des recherches seront effectuées. C'est pas de l'optimisation prématurée, mais quelque chose que vous devez décider de la phase de conception.

Le genre de l'optimisation de la Knuth règle est d'environ est de minimiser la longueur la plus courante codepaths, en optimisant le code qui est le, plus à, par exemple, la réécriture dans l'assemblée ou de la simplification du code, le rendant moins général. Mais cela n'a pas de l'utiliser jusqu'à ce que vous êtes certain que des parties de code a besoin de ce type d'optimisation et optimisation de la volonté (pourrait?) rendre le code plus difficile à comprendre ou à maintenir, d'où "l'optimisation prématurée est la racine de tout mal".

Knuth a également dit qu'il est toujours préférable, plutôt que de faire de l'optimisation, de modifier les algorithmes de votre programme, l'approche qu'il faut pour un problème. Par exemple, alors qu'un peu de peaufinage pourrait vous donner une augmentation de 10% de la vitesse avec l'optimisation, de changer fondamentalement la façon dont votre programme fonctionne peut en faire 10 fois plus rapide.

En réaction à beaucoup d'autres commentaires publiés sur cette question: algorithme de sélection != optimisation