À quel moment devriez-vous commencer à penser à la performance?

Au fur et à mesure que je crée des applications, je me demande constamment si c'est la meilleure façon d'effectuer ou d'implémenter une certaine fonctionnalité. Souvent, je posterai des questions sur stackoverflow ou un autre forum désirant des commentaires uniquement pour recevoir des commentaires sur la façon de ne pas "mettre le chariot avant le cheval" concernant les performances. La plupart des programmeurs ne pensent-ils vraiment pas aux performances tant que l'application n'est pas terminée, ou que les performances sont absolument inacceptables ?? Je veux dire, je comprends que les environnements de développement diffèrent des environnements de production et que vous ne devriez pas vous fier entièrement aux résultats de votre ordinateur portable de développement ... mais, il existe des pratiques et des techniques qui donnent de meilleures performances que d'autres.

Est-ce une mauvaise pratique de considérer les performances tout au long du processus de développement? Dois-je repousser ces considérations jusqu'à ce que les performances atteignent réellement le niveau ??

Mise à jour

Pour être clair, je parle de la situation dans laquelle vous envisagez ou êtes sur le point de travailler sur une fonctionnalité. Vous savez qu'il existe plusieurs façons de l'implémenter, mais vous ne savez pas exactement dans quelle mesure chaque implémentation évoluera. Il peut également y avoir plusieurs techniques que vous ne connaissez même pas. À petite échelle, n'importe laquelle des approches serait probablement adéquate, mais à plus grande échelle, certaines suivront et d'autres non. Souvent, lorsque je demande des avis ou des conseils, la réponse est: inquiétez-vous plus tard ...

Le report des considérations de performance est parfois basé sur une mauvaise application de la phrase:

L'optimisation prématurée est la racine de tout Mal.

Si vous lisez la citation complète, ce que Knuth essayait de dire est que les micro-optimisations appliquées pendant le développement sans profilage sont généralement déconseillées, car elles conduisent à un code moins maintenable sans nécessairement obtenir des avantages de performances substantiels.

Mais cela ne signifie pas que vous ne devriez pas considérer les performances jusqu'à ce que l'application soit presque terminée. Si vous faites cela, vous constaterez peut-être que les performances sont inadéquates, votre architecture de conception ne prend pas en charge de meilleures performances et vous devez recommencer.

Il existe un certain nombre de choses que vous pouvez faire pendant le développement pour obtenir de bonnes performances, sans optimisations ésotériques (et prématurées):

1. Utilisez une architecture sensée et bien pensée.
2. Utilisez correctement les structures de données.
3. Utiliser des technologies (bibliothèques, frameworks) qui fonctionnent correctement.

Si vous faites ces choses, vous constaterez que toute optimisation des performances qui doit se produire sera limitée à une petite partie de votre code. Le profilage identifiera ce code et vous permettra de concentrer vos améliorations de performances là où elles feront le plus de bien, sans sacrifier la maintenabilité.

Voici ce qu'il ne faut PAS penser:

• Est ++iplus rapide que i++?
• Est switchplus rapide que if?
• Dois-je inlinemes fonctions?
• Les fonctions virtuelles sont-elles lentes?
• C ++ / Java / C # est-il plus rapide / plus lent que l'autre?
• bla, bla, ...

Voici à quoi penser:

• Qu'est-ce qu'une charge de travail attendue réaliste?
• À quelle fréquence les informations saisies changent-elles et qui les fournit? Est-il sensé d'envisager une précompilation?
• Ai-je gardé ma structure de données aussi simple et aussi normalisée que possible? Cela signifie ne pas se soucier du hachage et des trucs comme ça.
• Ai-je gardé les notifications au minimum absolu? (C'est là que les changements dans une partie des données nécessitent des changements en même temps dans une autre partie, car la structure des données n'est pas normalisée.)

En ce qui concerne ce dernier point, d'après mon expérience, il est préférable de concevoir la structure des données de sorte que, si elle ne doit pas être normalisée, elle puisse tolérer une incohérence temporaire, qui peut ensuite être résolue par une sorte de balayage périodique. Un tueur majeur de performances est lorsque les notifications déclenchent d'autres notifications, qui se déclenchent davantage, dans une mesure que vous n'auriez jamais deviné auparavant. Et souvent, c'est un effort gaspillé à cause des changements à annulation automatique.

Si vous avez fait tout cela, vous avez un design épuré. Puis périodiquement au fur et à mesure que vous le développez, profilez. ( La pause aléatoire est la méthode sur laquelle je me fie.) Ensuite, si vous pouvez voir que les performances seraient améliorées en introduisant un algorithme plus sophistiqué, faites-le par tous les moyens.

Non, vous devez penser aux performances (en particulier dans la conception de bases de données) dès le départ. Il y a eu beaucoup de dommages à notre industrie par des gens qui pensent que toute optimisation est une optimisation prématurée. La citation était initialement destinée à empêcher les gens de regarder les micro-optimisations avant qu'un problème ne se soit produit. Il n'était pas prévu de ne faire aucune optimisation. Dans une base de données par exemple, il existe de nombreuses techniques connues qui fonctionnent mal. Les éviter, dans la conception, fait partie de ce que vous devez faire. Il est très difficile de refactoriser une base de données avec 100 000 000 d'enregistrements car elle a été conçue en utilisant des techniques de mauvaise perforation et nous ne pouvons plus éviter le problème en achetant un meilleur matériel.

Préoccupez-vous d'abord de l'exactitude ¹ , puis de la maintenabilité, puis de la sécurité et de la fiabilité, et ensuite vous pouvez penser aux performances. Appliquez cet ordre à chaque morceau de code pendant que vous le développez. Il est possible qu'une solution performante tombe naturellement du simple fait de garder les choses claires et directes.

80% des performances choisissent l'algorithme et la structure de données appropriés pour le problème en question; un tri rapide mal optimisé va toujours battre le pantalon d'un type de bulle hautement optimisé dans le cas moyen (le pire des cas, c'est un match nul).

Ce que tout le monde sur SO essaie de percer, c'est l'état d'esprit "qui est le plus rapide, ++ p ou p ++", où les gens sont tellement pris par la supercherie du compilateur qu'ils perdent la trace du problème plus large, ce qui entraîne un code cassant, un bug -ridden, mal , et le meilleur de tous, pas beaucoup plus rapide qu'une solution plus simple aurait été. J'ai traité ce genre de code de première main; un exemple était si fragile que nous ne pouvions apporter aucun changement sans le casser complètement.

¹ Où "exactitude" signifie "remplir la spécification", ce qui n'est pas synonyme de "sans bug".

Vous devriez commencer à penser à la performance une fois que vous savez ce qu'est une «bonne» performance. En d'autres termes, il serait faux de commencer à penser aux performances avant d'avoir identifié les seuils suivants:

• Performances inacceptables - corrigez-le maintenant avant qu'il ne devienne plus incontrôlable
• Performances acceptables - il est temps de se concentrer sur d'autres fonctionnalités avant d'essayer d'en faire plus avec les performances.
• Performances cibles - performances optimisées. Autrement dit, si vous disposez de suffisamment de temps et de ressources, que faudrait-il que votre système fasse?

Une fois que vous avez identifié ces seuils, vous avez également identifié la mesure que vous utilisez pour mesurer les performances. Cela signifie que vous pouvez configurer des tests de performances automatisés que vous pouvez exécuter plusieurs fois par jour. Cela vous dira si vous allez mieux ou pire.

Pour arriver à ces mesures, vous devez comprendre ce que votre système doit faire. Par exemple, des mesures de performances absolues sont-elles requises (réponse dans un délai X) ou des mesures de débit sont-elles requises (réponses X par temps Y)? Les optimisations de débit et de temps absolu nécessitent des approches différentes, et si vous ne savez pas ce qui est vraiment important, vous pourriez être en train d'optimiser dans le mauvais sens.

Vous avez probablement entendu dire que l'optimisation prématurée est la racine de tout mal. La question est ce qui le rend prématuré? À mon avis, ce n'est jamais une mauvaise idée de penser aux performances, mais ne vous inquiétez pas excessivement jusqu'à ce que votre code fonctionne. Une fois que cela fonctionne, faites des tests de charge lourde, profilez et identifiez les goulots d'étranglement, et optimisez vos performances.

Cela étant dit, il n'y a rien de mal à penser aux performances lors de la phase de codage initiale si vous connaissez certaines techniques qui feront une réelle différence. Par exemple, choisir une structure de stockage dans une bibliothèque plutôt qu'une autre parce que l'expérience passée vous a appris que l'une d'entre elles est plus rapide / utilise moins de RAM que l'autre. Ou créer un système de mise en cache simple (vous pouvez le rendre plus sophistiqué si des tests ultérieurs l'exigent) pour les données que vous connaissezsera accessible beaucoup et serait beaucoup mieux mis en cache. De cette façon, vous ne vous inquiétez pas trop des performances (du moins pas au début), mais vous utilisez des conseils et des astuces que vous avez appris en cours de route avec d'autres projets. Essayez de garder ces éléments simples afin qu'ils soient faciles à inclure lors du développement initial, et peuvent également offrir certains avantages.

Les performances doivent être détaillées dans les spécifications système et utilisateur de votre document d'exigences. Je sais que de nombreuses personnes se moquent de l'idée d'entreprendre une analyse des exigences dans le développement d'une application, mais étonnamment, un tel document répondra de manière concise à quoi et où vous devriez consacrer vos ressources liées aux performances à mesure que l'application approche de son achèvement. Et il répondra à cette question en temps opportun

La documentation des exigences vous fera économiser des centaines d'heures de temps qui seraient autrement gaspillées sur des processus non essentiels.

Une approche équilibrée serait préférable. Les performances sont importantes mais pas aussi importantes que faire avancer les choses, donc:

1. créez d'abord une fonctionnalité en essayant de réfléchir un peu à ce que vous faites et à la façon dont vous le faites (utilisez un peu de temps pour réfléchir aux performances, mais pas beaucoup)
2. Essaye-le
3. une fois qu'il fonctionne, commencez à réfléchir à la nécessité réelle de l'améliorer (en général, vous ne le ferez pas, mais dans certains cas, vous pourriez).

C'est mon approche commune de la performance vs de la fonctionnalité, et dans les cas généraux, tout dépend de ce que fait le programme et de vérifier s'il est nécessaire d'améliorer les choses et combien de temps cela me coûterait.

Pensons à un site Web de questions-réponses comme celui-ci, je pense que ceux qui l'ont derrière ont sûrement beaucoup réfléchi à la façon de poser la question et d'obtenir la réponse le plus rapidement possible. Mais, lorsque vous pensez aux notifications, cela n'a pas vraiment d'importance si les notifications apparaissent de temps en temps et vous indiquent qu'il y a une nouvelle réponse ou quelque chose.

Il existe un moyen de différer en toute sécurité la réflexion sur les performances: utiliser des langages spécifiques au domaine dans la mesure du possible.

Si la plupart de votre développement peut être fait avec vos propres petits DSL, et qu'ils sont suffisamment bien conçus pour exprimer votre domaine problématique sous la forme la plus générique et la plus élevée, il est possible d'obtenir un prototype fonctionnel en premier, sans jamais penser à performances, puis améliorez uniquement vos implémentations DSL, pas le code de domaine réel du problème.

C'est également une bien meilleure approche du point de vue de la maintenabilité.

Vous devez tenir compte des performances. Cependant, vous devez tracer une ligne pour marquer la fin du réglage, car (généralement) votre temps est plus important que celui de l'ordinateur.

Un très bon article textuel sur les performances est: The Computer Performance Shell Game .

Le jeu shell de performances informatiques, également appelé "trouver le goulot d'étranglement", se joue toujours entre ces quatre ressources:

• CPU
• Disque
• Réseau
• Mémoire

À tout moment, votre ordinateur attend la fin d'une opération sur l'une de ces ressources. Mais lequel: CPU, mémoire, disque ou réseau? Si vous êtes intéressé par les performances, la première chose absolue que vous devez faire est de déterminer lequel de ces goulots d'étranglement entrave actuellement les performances - et de les éliminer.

Le «meilleur» moyen est un terme très chargé, et la réponse peut dépendre fortement de facteurs inconnus jusqu'à l'exécution.

• Avez-vous beaucoup de mémoire? - vous obtiendrez de meilleures performances avec une structure de données «tout-en-mémoire», mais si vous n'avez pas assez de mémoire, le swap tuera vos performances.
• Avez-vous besoin de persévérance? Une base de données donne l'intégrité mais est plus lente que la structure de données "tout en mémoire" ci-dessus. BEAUCOUP plus lent.
• Pouvez-vous mettre en cache les résultats? Le vernis peut vous aider! http://www.varnish-cache.org/

La liste se rallonge de plus en plus.

Ce que vous pouvez faire, est d'écrire « la chose la plus simple qui pourrait éventuellement travailler » de la connaissance que vous actuellement n'ont, et de le faire dans un modulaire mode de sorte que vous pouvez facilement réorganiser quand vous en savez plus. Notez que la chose "la plus simple" n'est pas nécessairement simple!

C'est toujours quelque chose que vous devez garder à l'esprit. Je pense que ce que la plupart des gens essaient de dire, c'est qu'il ne sert à rien de passer deux jours à essayer d'optimiser quelque chose que vous ne savez même pas cassé. Une fois que vous avez un produit en cours d'exécution et que vous pouvez effectuer des tests d'utilisabilité, cela devrait vous montrer où vous rencontrez des problèmes de performances. Ensuite, une fois que vous pouvez identifier les vrais problèmes de performances, vous pouvez cibler les optimisations que vous devez effectuer.

En théorie au moins, vous devriez commencer à penser aux performances une fois que vous êtes en test bêta et pas avant.

Ce n'est cependant pas une licence pour prendre de mauvaises décisions de conception. Par exemple, l'utilisation d'une chaîne NVARCHAR comme clé primaire est un chemin sûr vers de mauvaises performances; cela dit, c'est une habitude dégoûtante quels que soient les problèmes de performances et vous ne devriez pas utiliser en premier lieu.

Si votre conception suit les meilleures pratiques conventionnelles (tout sous la 3ème forme normale, les informations correctes se cachant dans vos classes, l'utilisation minimale des singletons, etc.), et qu'il y a un problème de performances plus tard, ce sera facile à gérer (créez un index ici, y implémenter un cache).

HTH

Ça dépend. Il est utile de garder à l'esprit la règle 80/20: la plupart (disons 80%) du code de l'application ne sera jamais exécuté assez souvent pour faire une différence notable dans les performances. Vous devez vous concentrer sur les 20% restants où l'application est appelée à passer environ 80% de son temps d'exécution.

Vous pourrez peut-être identifier à l'avance certains des points chauds de performance évidents, comme si vous savez qu'un calcul particulier va être répété des millions de fois. Dans de tels cas, il vaut vraiment la peine de penser à l'optimiser dès le départ en choisissant les bonnes structures de données et les algorithmes pour le travail.

Cependant, cette optimisation est plus une activité de conception. Ce qui est généralement sans valeur, ce sont les micro-optimisations, où quelqu'un passe énormément de temps avec des astuces astucieuses pour bidouiller au nom de "gagner en performances". Surtout s'ils sont effectués sans mesures appropriées avant et après, de tels changements peuvent ne faire aucune différence ou ralentir réellement l'application dans des circonstances réelles.

Cela dépend du stade de développement dans lequel vous vous trouvez

1) Si vous construisez des fonctionnalités de votre logiciel, continuez à le faire fonctionner et assurez-vous qu'il fonctionne correctement (c'est-à-dire souhaité et efficace).

2) Une fois les blocs de construction intégrés, vous obtiendrez un soupçon de consommation de ressources, là vous avez de la place pour l'optimisation.

Si vous devez commencer à penser à la performance, vous avez des ennuis. Vous devriez toujours penser à la performance. En fait, je soupçonne que les bons programmeurs vont penser à la performance même s'ils n'en ont pas l'intention, à la manière des «hommes pensent au sexe toutes les sept secondes».

Ce qui est important, c'est les actions que vous entreprendrez en fonction de toute cette réflexion. Les pensées sont bon marché, mais les actions peuvent briser le code et faire sauter les délais.

La plupart du temps, la seule action sensée sera de ne rien faire: vous avez identifié que votre morceau de code ne sera pas appelé assez souvent pour que les problèmes de performances soient observables - c'est peut-être un morceau de code de démarrage qui s'exécute une fois par ordinateur pendant 1% de votre base d'utilisateurs potentiels, c'est peut-être un petit code de serveur redondant noyé dans une mer d'accès lents à la base de données, c'est peut-être juste une affectation entière dans une section de code non critique.

Très souvent, vous pensez qu'une opération donnée peut entraîner un problème de performances qui pourrait être résolu par une simple modification. Il y a, par exemple, le sentiment persistant que l'exécution d'une requête SQL complexe sur chaque demande, ou une demande pour le même élément de données à partir d'un dictionnaire deux fois, sera mauvaise pour vous. C'est là que la connaissance des techniques d'optimisation est utile, et peut-être la conclusion la plus surprenante se produit:

Si vous connaissez une technique rapide qui améliorera presque certainement les performances d'un morceau de code, ne le faites pas.

Si vous pouvez y penser maintenant, vous pouvez certainement le faire en cinq minutes plus tard. Le garder hors du code (mais peut-être dans un // TODOcommentaire) laisse le code plus propre et vous fait gagner du temps pour travailler sur une autre fonctionnalité, sans perdre de temps si vous finissez par jeter ce code plus tard. Si le code d'origine s'avère causer des problèmes de performances lors du test, revenez en arrière et appliquez votre technique rapide.

Je ne dis pas ici que vous devez éviter d'écrire du code idiomatique simplement parce qu'il se trouve être plus rapide. Écrivez du code idiomatique selon les meilleures pratiques qui améliorent la productivité et la lisibilité et réduisent les bogues. C'est juste que si vous avez le choix entre un code idiomatique et une alternative plus rapide mais facilement écrite, optez toujours pour la lisibilité au lieu de la vitesse.

La seule situation difficile est quand il ne semble pas y avoir de moyen facile d'améliorer les performances du code, et pourtant il est douloureusement évident qu'un morceau de code va se casser dès qu'il est livré - une traversée complète de la base de données à chaque clic, une centaine de requêtes SQL par page sur le site, ou quoi que ce soit de même terrible. C'est là que vous devez réellement vous arrêter et réfléchir davantage. Ce sont généralement des problèmes d'architecture qui ne peuvent de toute façon pas être résolus à l'échelle locale. Confirmez vos soupçons avec un pic rapide ou un prototype, recherchez des expériences similaires et des solutions communes, et envisagez soit un changement d'architecture soit une baisse de fonctionnalités.

À mon humble avis, il est important de penser aux performances avant de mettre en œuvre le système, mais ne pensez qu'à. Vous devez analyser l'application et découvrir quels pourraient être les goulots d'étranglement potentiels en termes de performances.

Implémentez ensuite le système le plus simplement possible. Si des problèmes de performances surviennent, optimisez.

Par exemple, supposons que vous ayez un client GUI qui obtient des données via une sorte de service (SOAP, HTTP REST, etc.). Ensuite, la chose la plus importante pour une performance / évolutivité élevée est d'avoir le moins d'appels possible, chaque appel renvoyant beaucoup de données, plutôt qu'un grand nombre d'appels renvoyant un peu d'informations chacun, c'est-à-dire préférant une communication volumineuse à une conversation.

Lors de la mise en œuvre de ce type de système, je me fiche du nombre d'appels entre le système. Mais je ferais en sorte que la base de code me permette de refactoriser / optimiser facilement lorsque les besoins se présentent.

Vous devez penser aux performances de manière très générale dès le départ. Vous devez sélectionner des structures de données et des algorithmes qui fonctionneront bien pour votre application et seront raisonnablement efficaces. Les algorithmes sont fondamentaux pour le logiciel, et les structures de données plus encore. Vous devrez probablement effectuer des réécritures majeures si vous devez apporter des modifications majeures à l'une ou l'autre, tandis que les petits détails peuvent être réécrits plus facilement.

Vous voudrez peut-être également adopter des habitudes efficaces, mais celles-ci dépendront de la langue. En C ++, par exemple, "++ i;" en tant qu'instruction ou expression autonome est toujours au moins aussi bonne que "i ++;", et pourrait potentiellement être beaucoup plus efficace. Dans la plupart des cas, cependant, vous devez écrire du code clair et faire confiance au compilateur. Prendre l'habitude de s'inquiéter des micro-efficacités vous causera presque certainement plus de problèmes qu'elle n'en résout. Pour les applications de bureau, le compilateur est au moins aussi intelligent que vous sur des choses commei >> 1 vs i / 2, soit la meilleure façon d'améliorer les performances est d'obtenir un meilleur compilateur, alors ne vous inquiétez pas.

Au-delà de cela, ne vous inquiétez pas tant que vous n'avez pas quelque chose que vous pouvez tester. À ce moment-là, vous pouvez profiler le programme pour voir où se trouvent les points chauds et probablement vous faire une idée si vous avez un programme de performance ou non. Si vous devez améliorer les performances, recherchez où le programme passe la plupart de son temps et améliorez les choses là-bas. Si vous avez conçu avec une efficacité globale adéquate et bien écrit le programme, vous ne modifiez qu'une partie relativement petite du programme.

Je pense que le mieux que vous puissiez faire est de suivre de bonnes pratiques de conception (par exemple, ne faites pas ce que vous savez qui entravera les performances) jusqu'à ce que quelque chose fonctionne. Si vous ne pouvez pas mesurer l'amélioration, vous ne pouvez pas faire d'amélioration. Une fois que vous avez quelque chose que vous pouvez tester, c'est souvent une bonne idée de faire un profilage et de vous faire une idée des points chauds (le cas échéant). Si quelque chose vous saute aux yeux, vous devriez envisager de refactoriser ou de réécrire la zone à problème, mais si ce n'est pas trop mal (tout simplement parce que le code passe 90% de son temps en deux ou trois méthodes ne signifie rien s'il fonctionne correctement dans l'ensemble) alors continuez à vous développer. J'ai vu plus d'une fois des développeurs qui passent des jours à optimiser la partie la plus complexe du système,

Quand devrais-je commencer à y penser? Combien d'efforts dois-je y consacrer? Cela dépend de la échelle Cockburn du projet. (En d'autres termes, quel est le risque de ne pas avoir de bonnes performances?)

Apprenez les bases bien à l'avance (voir Robert Harvey's réponse de ). Afin d'appliquer une pensée axée sur les performances à différentes étapes du développement logiciel, le développeur doit le connaître à fond, afin que le processus de réflexion ne soit pas entravé par ces considérations supplémentaires. (En d'autres termes, commencez à penser à la performance avant la conception du projet.)

Au début du développement, utilisez généreusement les outils de profilage des performances et gardez une trace de l'historique des statistiques. Portez une attention particulière à l'organisation de ces informations afin de les rendre utiles pour une prise de décision ultérieure.

Ensuite, selon la nature de votre projet et son échelle Cockburn:

• Prototypage rapide, ou "bang out code comme s'il n'y a pas de lendemain", ou développement en interne avec un faible impact commercial: il suffit de garder les statistiques. Ne pensez pas encore aux performances. Implémentez la fonction de la manière la plus simple. Restez avec le premier algorithme qui vous vient à l'esprit.

  • Dans la seconde moitié du projet, des tests de performance ad hoc seront effectués pour identifier les «points chauds» en fonction des cas d'utilisation réels. S'il y a un problème de performances qui rend le logiciel inutilisable, il doit être facilement identifiable.
  • Pour un développement en interne avec un faible impact commercial, déployez simplement le code et corrigez les problèmes de performances ultérieurement.

• Les applications de bureau, qui nécessitent une approche cohérente et complète des performances. Il n'a pas besoin d'être hautement optimisé; cependant, il devrait y avoir aussi peu de "blocages" (non-réactivité) que possible.

  • Les applications de bureau ont généralement des chemins d'exécution très compliqués, ce qui complique la réflexion axée sur les performances. Une conception en couches permettra de séparer les problèmes de performances de la base de données / réseau des problèmes de performances de l'interface graphique, à gérer par différents experts de votre équipe.
  • Un historique des traces Log permettra d'identifier les hotspots.

• Calcul haute performance, qui nécessite de tirer le meilleur parti du matériel.

  • Désignez un membre de votre équipe pour être en charge d'analyser et de rapporter les statistiques de performance.
  • Faites des théories sur les caractéristiques de performance, vérifiez-les avec des expériences et comparez avec vos prédictions à partir de modèles Comp Sci simplifiés.
  *

Au début. Identifiez les caractéristiques de performance requises. Si vous ne pouvez pas identifier la cible, vous devez soit prendre du recul pour mieux comprendre vos besoins, soit reporter jusqu'à ce que vous connaissiez les besoins de vos composants avec le risque que vous soyez en train de réécrire. Ensuite, testez. N'optimisez pas, testez. Si votre code échoue au test de performances, optimisez. Avec un cadre de test en place, l'utilisation des outils de surveillance des performances existants devrait faciliter la tâche.

Gardez les tests de performances en place pendant toute la durée de vie du projet en tant que test de régression. Le code de maintenance est connu pour déclencher des problèmes de performances car les «correctifs» ont souvent une focalisation très étroite.

Je m'appuie toujours sur une formule simple:

1. Fais-le fonctionner
2. Fais-le bien
3. Faites vite

... dans cet ordre.

Selon c2 , cette formulation est attribuée à Kent Beck .