Puisque je suis un développeur isolé, je dois réfléchir à tous les aspects des systèmes que je travaille. Dernièrement, j'ai réfléchi à la performance de mes deux sites Web et de moyens de l'améliorer. Des sites tels que Stackoverflow proclama, "la performance est une fonctionnalité". Cependant, "l'optimisation prématurée est la racine de tout mal" et aucun de mes clients ne s'est encore plaint de la performance des sites.
Ma question est que la performance est-elle toujours importante? Si la performance devrait toujours être une fonctionnalité?
Remarque: je ne pense pas que cette question soit la même que Celui-ci , car cette affiche demande quand envisager la performance et que je demande si la réponse à cette question est toujours, et si oui, pourquoi. Je ne pense pas non plus que cette question soit cw, car je pense qu'il y a une réponse et un raisonnement pour cette réponse.
15 Réponses :
Les performances adéquates sont toujours importantes.
la performance absolue la plus rapide possible n'est presque jamais importante.
Il vaut toujours la peine de garder un œil sur la performance et d'être conscient de tout ce que vous scandaleusement non optimal que vous faites (en particulier à un niveau de conception / architecture), mais ce n'est pas la même chose que la micro-optimisation chaque ligne de code.
Cela est vrai pour les applications, mais pas pour les bibliothèques.
SBI: Même pour les bibliothèques, vous n'avez souvent pas besoin du moyen le plus rapide absolu de faire des choses. Faire votre code extrêmement compliqué pour faire une amélioration minimale qui n'améliore pas la complexité de l'opération ne vaudra souvent pas la peine. De toute évidence, le public plus large et plus diversifié de votre bibliothèque, plus la performance est importante.
@Jon: Bien sûr, tout comme il existe des applications où la performance ne peut jamais être assez rapide, il y a donc des bibliothèques où la performance n'a pas d'importance. Cependant, IME, la règle générale est de rendre les applications aussi rapides que nécessaire et les bibliothèques le plus rapidement possible. Mais cela pourrait dépendre de la culture que vous avez de: en C et C ++, écrire une bibliothèque de journalisation qui ne peut pas effectuer au moins aussi vite que le manuel printf () est considéré comme un crime majeur. En Java, personne ne s'en soucierait probablement. Je suis ton gars de la prochaine porte C ++. :)
J'utiliserais "adéquat" avec "bon". Une performance adéquate est d'une importance pratiquement critique. Les bonnes performances peuvent presque toujours être faites simplement avec une bonne conception, pas des micro-optimisations.
@SBI: Vous avez raison que le jeu est différent pour les bibliothèques - vous ne savez pas comment allez-vous être touché. Mais même pour les bibliothèques, je trouve concevoir une interface que peut être aussi rapide que possible plus difficile que la mise en œuvre réelle elle-même.
@peterchen: Je suis entièrement d'accord. Une fois que vous avez gêné l'interface Performance-Wise, aucune quantité de code de code ne peut vous obtenir de performances maximales.
@jon: haute performance! = complexité dans la plupart des situations. Cependant, ce que j'ai trouvé, c'est qu'une équation différente fonctionne généralement mieux: la simplicité conduit à des pistes de haute performance à la stabilité conduit à la sécurité.
@Chris: Mon expérience est que le code le plus simple n'est généralement pas le code le plus rapide possible. Je serais d'accord avec la simplicité menant à la stabilité et à un vent suivant).
Règles d'optimisation de Jackson:
règle 1. Ne le faites pas.
règle 2 (pour les experts uniquement). Ne le fais pas mais c'est, pas avant d'avoir un parfaitement clair et non optimisé Solution.
-m. A. Jackson
extrait de code complète 2e édition.
Qui s'applique principalement aux micro-optimisations.
Il est plus important de faire fonctionner la logique du programme que de faire chaque méthode le plus rapidement possible. N'oubliez pas que 80-90% de votre code est exécuté moins de 10% du temps et ne vous achètera donc rien si cela est optimisé.
"Optimisation" ne signifie pas "rendre chaque méthode aussi vite que possible". L'optimation la plus importante se produit réellement pendant la conception. "Faites-le bien, puis de le rendre rapide" s'applique à des méthodes individuelles, pas une application dans son ensemble.
Quelle est la performance importante dépend en grande partie et avant tout ce que vous faites.
Par exemple, si vous écrivez une bibliothèque pouvant être utilisée dans n'importe quel environnement, cela peut difficilement avoir trop de performances. Dans certains environnements, un avantage de performance de 10% peut être une caractéristique majeure pour une bibliothèque.
Si vous, OTOH, écrivez une application, il y a toujours un point où il est assez rapide. Les utilisateurs ne se rendront ni ne se soucient ni ne se soucient pas de savoir si un bouton enfoncé réagit à moins de 0,05 ou 0,2 seconde - même si c'est un facteur de 4.
Cependant, il est toujours plus facile d'obtenir du code de travail plus rapidement, qu'il ne s'agit d'obtenir du code rapide.
En fait, je pense que les utilisateurs le remarqueront si cela prend la 5ème d'une seconde pour répondre à un bouton, surtout si elles sont utilisées pour une réponse immédiate dans des programmes similaires. Dis peut-être 0,01 et 0,04 secondes (ce qui est également un facteur de 4, mais ne vaut certainement pas la peine de devenir fou).
@Unclebens: Je viens d'essayer d'ouvrir quelques dialogues sur le Firefox, je le vois avec. Je suppose que l'ouverture de la boîte de dialogue Options pour la première fois, il a fallu au moins 0,2Secs pour qu'il apparaisse après avoir cliqué sur l'élément de menu. La même chose pour la boîte de dialogue Organisation des favoris. L'ouverture d'un nouvel onglet a probablement pris même 0.5Secs. Oui, cela est réellement perceptible, mais ce sont toujours des retards «normaux» que la plupart d'entre nous ne remarqueront même pas d'interaction quotidienne avec les programmes que nous utilisons. La plupart des applications se contenter de cela en tant que suffisamment d'utilisateurs et la plupart des utilisateurs ne donnent pas l'esprit.
performance! = Optimisation.
performance est une fonctionnalité en effet, mais l'optimisation prématurée vous coûtera du temps et ne donnera pas le même résultat que lorsque vous optimisez les pièces qui ont besoin d'optimisation. Et vous ne pouvez pas vraiment savoir quelles parties ont besoin d'optimisation jusqu'à ce que vous puissiez profiler quelque chose.
Performance est la fonctionnalité que vos clients ne vous diront pas si c'est manquant, à moins que ce soit vraiment douloureusement lent et qu'ils sont obligés d'utiliser votre produit. Les clients existants peuvent le signaler à la fin, mais les nouveaux clients ne se dérouleront tout simplement pas si la performance est requise.
Vous devez savoir quelles performances vous avez besoin et la formulent comme une exigence. Ensuite, vous devez rencontrer votre propre exigence.
J'ajouterais que cette optimisation prématurée ne coûtera pas seulement du temps de coûts, mais aussi souvent de la clarté du code de coûts, rendant le code plus difficile du refacteur. Ensuite, vous pouvez vous retrouver avec des problèmes lorsque vous essayez d'optimiser les parties vraiment importantes ...
... et je suis d'accord avec ça.
La performance n'est importante que dans la mesure où l'élaboration de l'amélioration des performances prend moins de temps que la durée totale qui sera enregistrée pour les utilisateurs.
Le résultat est que si vous développez quelque chose pour des millions ... Ouais, il est important de les sauvegarder le temps. Si vous codez un outil pour votre propre usage ... Cela pourrait être plus de problèmes qu'il ne vaut pas la peine d'économiser une minute, voire une heure ou plus.
(Ce n'est clairement pas une règle dans la pierre ... Il y a des moments où la performance est vraiment cruciale, peu importe la quantité de temps de développement nécessaire)
Il devrait y avoir un équilibre à tout. Coût (ou le temps de développer) vs performance par exemple. Plus de performance = plus de coût. Si une exigence du système en cours de construction est élevée, le coût ne devrait pas avoir d'importance, mais si le coût est un facteur, vous optimisez dans la raison. Après un certain temps, votre retour sur investissement en souffre dans la mesure où plus de performance n'entraîne pas plus de rendements.
L'importance de la performance est l'IMHO fortement corrélé à votre problème. Si vous créez un site avec une attente d'une charge lourde et de beaucoup de traitement latéral du serveur, vous voudrez peut-être mettre plus de temps en performance (sinon votre site pourrait finir par être inutilisable). Toutefois, pour la plupart des applications, le temps mis en optimisation de votre performance sur un site Web ne va pas payer - les utilisateurs ne remarqueront pas la différence.
Donc, je suppose que ça se décompose à ceci:
Les utilisateurs remarqueront-ils les améliorations? Comment cette amélioration se compare-t-elle aux sites concurrents?
Si les utilisateurs remarqueront et que l'amélioration serait suffisante pour vous différencier de la concurrence - la performance est une caractéristique importante - sinon pas beaucoup. (À un point - je ne recommande pas de l'ignorer entièrement - vous ne voulez pas que votre site soit tortue après tout).
Dans la plupart des applications 90% ou plus du temps d'exécution est dépensé en 10% ou moins du code. Habituellement, il est peu utilisé dans l'optimisation d'un autre code que ces 10%.
garder les performances à l'esprit mais compte tenu de votre situation, il serait imprudent de passer trop de temps à l'avant dessus.
performance est important, mais il est souvent difficile de savoir où sera votre goulot d'étranglement. Je suggère donc que la planification de consacrer un peu de temps à cette fonctionnalité une fois que vous avez quelque chose à travailler.
Ainsi, vous devez configurer Si c'est Web, il serait sage de noter votre taille et vos performances de la page à l'aide de Firebug +
Pour donner une réponse généralisée à une question générale:
premier le faire travail , alors le faire droit , alors faire il http://c2.com/cgi/wiki?MakeitworkMakeIrightMakeFast
Cela met une perspective plus constructive sur "L'optimisation prématurée est la racine de tout mal".
Donc, pour parallèlement à la réponse de Jon Skeet, une performance adéquate (dans le cadre de la fabrication de quelque chose de travail, et de la rendre correcte) est toujours importante. Même alors, il peut souvent être abordé après d'autres fonctionnalités.
Je dirais d'abord obtenir le droit de travailler puis d'améliorer les performances.
que "la racine de tout mal" devote est presque toujours mal utilisé et mal compris.
Conception de votre application Pour bien performer peut être principalement fait avec une bonne conception. Bon design! = Optimisation prématurée, et il est tout à fait ridicule de sortir de l'écriture de code de merde et de souffler faire un meilleur travail sur la conception comme un gaspillage "mal". Maintenant, je ne parle pas spécifiquement de vous ici ... mais je vois que les gens font cela beaucoup.
Il est généralement sauve vous avez temps de faire un bon travail sur la conception. Si vous mettez l'accent sur cela, vous allez aller mieux à cela ... et obtenez-vous plus vite et plus vite aux systèmes d'écriture qui fonctionnent bien du début.
Comprendre quels types de structures et méthodes d'accès fonctionnent mieux dans certaines situations sont essentielles ici.
Bien sûr, si vous êtes une application devient vraiment massif ou contient des exigences de vitesse insensées, vous pouvez vous retrouver à faire des optimisations de votre code qui rendent votre code le plus fiable ou plus difficile à entretenir ... et il serait faux de faire ces choses avant de besoin à.
mais c'est absolument pas la même chose que de faire un effort pour comprendre et utiliser les algorithmes de droite ou les modèles de données ou quoi que ce soit en premier lieu.
Vos utilisateurs ne vont probablement pas se plaindre de mauvaises performances si elle est supportable. Ils ne le sauraient même pas que pourraient être être plus rapides. Réagir aux plaintes en tant que pilote primaire est un mauvais moyen d'exploiter. Bien sûr, vous devez faire face aux plaintes que vous recevez ... mais un manque d'entre eux ne signifie pas qu'il n'y a pas de problème. Le fait que vous envisagez d'améliorer les performances est un peu un indicateur là-bas. Était-ce juste un caprice ou une partie de vous vous dit que cela devrait être meilleur? Pourquoi avez-vous envisagé l'améliorer?
Ne faites rien de devenir fou faire des choses inutiles.
non. Assez rapide est généralement assez bon.
Ce n'est pas nécessairement vrai que les idées de votre client sur «assez rapide» devraient l'emporter. Si vous pensez que c'est assez rapide et que votre client n'est pas alors oui, vous devez accueillir vos idées à la leur. Mais si vous êtes client pense qu'il est assez rapide et que vous ne devez pas envisager sérieusement d'aller avec votre opinion, pas de leur leur (puisque vous pouvez être plus bien informé des normes de performance dans le monde plus large).
Skeets Jon 'Adéquats' ongles, avec la disposition supplémentaire que pour une bibliothèque que vous ne connaissez pas encore ce qui est adéquat, il vaut donc préférable de vous tromper du côté sûr.
C'est l'un des nombreux enjeux que vous ne devez pas vous tromper, mais la qualité de votre application est largement déterminée par le lien le plus faible.
performance est définitivement toujours important dans un certain sens - peut-être pas celui que vous voulez dire: à savoir toutes les phases de développement.
Dans la grosse notation, ce qui est à l'intérieur des paranthèses est en grande partie décidé par la conception - l'isolement des composants et le stockage de données. Le choix de l'algorithme ne sera généralement que le meilleur / le pire comportement des cas (à moins que vous ne commenciez avec des algorithmes résolument résolus). Les optimisations de code affecteront principalement le facteur constant - ce qui ne devrait pas être négligé, non plus.
Mais c'est vrai pour tous les aspects du code: à n'importe quelle étape, vous avez de bonnes chances d'échouer tout aspect - stabilité, maintenabilité, compatibilité, etc. La performance doit être équilibrée, de sorte qu'aucun aspect ne soit laissé en arrière.
performance est quelque chose à concevoir dès le départ, non clouté à la fin. Au cours des 15 dernières années, je travaille dans l'espace d'ingénierie de la performance et la cause de la plupart des échecs de projet que je travaille est un manque d'exigences en matière de performance. Quelques postes ont noté «assez rapide» comme une observation et si votre attente correspond à celle de vos clients, mais qu'en est-il lorsque vous avez une situation de votre client, votre équipe architecturale, votre équipe d'ingénierie de plateforme, votre équipe de test fonctionnelle, votre L'équipe de test de performance et votre équipe d'opérations ont toutes des attentes différentes sur les performances, dont aucune n'a été commise à la pierre et à mesurer. Mauvaise magie à être certaine.
Capturez ces attentes de la part de vos clients. Engagez-les à une exigence spécifique, objective et mesurable que vous pouvez évaluer à chaque étape de la production de votre logiciel. Les attentes peuvent ne pas être uniformes, une seule section de votre application / code ayant besoin d'être plus rapide que d'autres, ni que chaque client n'a que les mêmes attentes sur ce qui est considéré comme acceptable. Avoir cette information vous obligera à confronter les décisions de la conception et de la mise en œuvre que vous avez peut-être négligées dans le passé et il se traduira par un produit qui correspond au mieux aux attentes de vos clients.