Comme le code d'aujourd'hui devient plus complexe à la minute, le code doit être conçu pour être gardé - ce qui signifie facile à lire, et facile à comprendre.
Cela étant dit, je ne peux m'empêcher de ne pas m'empêcher de me souvenir des programmes qui ont couru il y a quelques années telles que Winamp ou certains jeux dans lesquels vous aviez besoin d'un programme de haute performance, car votre 486 100 MHz ne jouerait pas aux mp3 avec ce beau Lecteur MP3 qui consommait tous vos cycles de processeur.
Maintenant, je gère Média Player (ou autre), commencez à jouer un MP3 et il mange un de 25-30% de l'un de mes quatre cœurs. Allez!! Si un 486 peut le faire, comment la lecture peut-elle prendre autant de processeur pour faire la même chose?
Je suis un développeur moi-même, et j'ai toujours l'habitude de conseiller: Gardez votre code simple, n'opiez pas prématurément pour les performances. Il semble que nous allions de "essayer de l'obtenir d'utiliser le moins de CPU le plus possible" à " si cela ne prend pas trop de processeur est tout de suite ". ".
Alors, pensez-vous que nous meurons des performances en ignorant les optimisations?
10 Réponses :
Le code de nettoyage ne tue pas la performance. Le mauvais code tue la performance.
Bien placé. Un algorithme propre va surperformer un mauvais algorithme "réglé". En ce qui concerne les applications de l'interface graphique, certains développeurs ne comprennent pas comment les interfaces utilisateur entraînées par des données et des événements sont assemblées et que les alternatives «Brute Force» aboutissent à ce que vous décrivez. Ce n'est pas une clarté du code, c'est la naïveté du code.
Personnellement, je m'efforce toujours d'un équilibre entre la performance et la maintenabilité. Nous avons longtemps quitté les jours où le temps de processeur était coûteux et que les programmeurs étaient bon marché, mais comme un utilisateur ainsi que le développeur, il est frustrant comme l'enfer de trouver les mêmes tâches qui prenaient plus de temps sur les nouvelles éditions du même logiciel fonctionnant sur plus récente, plus rapidement. matériel ... Donc, subjectivement, oui, je pense que certaines entreprises sont allées trop loin dans l'autre sens.
Je pense que la performance est en corrélation avec la maintenabilité, pas contre.
Pour la plupart, oui, mais ce que je voulais avoir (mal) était plus important de ce que vous avez souligné dans votre propre réponse; J'ai vu un code «super-factible» qui n'était pas seulement lent, mais pour moi au moins plus difficile à suivre. Comme je l'ai dit, "équilibre". Pour abuser de la règle 80/20, la majorité des applications n'ont pas besoin de la performance ultime, mais comme l'orientation d'objet est devenue omniprésente, les applications sont devenues (du point de vue de l'utilisateur, au moins) plus lentes et plus gonflées, tandis que le matériel Les vitesses continuent d'améliorer. D'où vient la disparité de la performance?
Les développeurs ne devraient pas avoir peur d'optimiser leurs applications. Le bloat et la lenteur des applications d'aujourd'hui sont épouvantables.
++ Ne pas répéter être redondante répétitif, mais vous avez raison. Stackoverflow.com/questions/ 926266 / ...
Les développeurs devraient avoir peur d'optimiser. Les optimisations doivent être priorisées avec tout ce qui doit être fait, comme plus / meilleures caractéristiques, des corrections de bogues, des tests de convivialité, etc. Les développeurs ne devraient pas être la décision d'optimiser, à moins qu'ils ne soient également le propriétaire du produit.
Les optimisations après-le font doivent être prioritaires avec tout le reste, mais les optimisations doivent toujours être mises en œuvre en tant que développeur se développent en tant que plan d'action standard. Nous ne devrions pas écrire un code non optimal exprès (sans motifs accablants). Les propriétaires de produits ne doivent pas jouer dans les détails du développement.
Spécifiquement en ce qui concerne le lecteur MP3, vous ne comparez probablement pas comme avec comme. Votre ancien 486 lecteur MP3 a fait peu mais jouez le MP3, Media Player porte un guichet complet de Crufft faisant des effets fantaisistes, une interface Aero et tout ce genre de choses. Sans parler de cela est probablement à la maison de téléphonie et une douzaine d'autres endroits sur la planète pour laisser Microsoft savoir ce que vous inscrivez aussi: -)
En fait, je pense que cela est vrai plus de manière générique, le type d'expérience de l'interface utilisateur que nous sommes arrivés à attendre aujourd'hui vient à un prix à la fois en termes de processeur et de mémoire. Je pense que cela sera beaucoup plus significatif que toute surcharge supplémentaire de la structuration du code (et nos compilateurs plus aussi intelligents qu'aucun ans il ya 10 ans, donc je doute même qu'il s'agisse d'un facteur au niveau du code de la machine)
C'est ce que je pensais. iTunes utilise 9x - 10 fois autant de processeur avec le visualiseur comme il le fait sans. Et c'est avec des filtres (EQ, etc.) pour améliorer le son qui n'étaient probablement pas utilisés autant dans les 486 jours.
J'ai trouvé tout à fait le contraire d'être vrai. Le code le plus simple à lire et à maintenir a eu tendance, dans mon expérience, être le plus performant dans l'ensemble. Il s'agit des boules de boue gigantesques difficiles à lire qui ont tendance à avoir des goulots d'étranglement de la performance dans des endroits étranges presque impossibles à éliminer ou à refacteur, ils sont donc laissés là-bas.
++ je suis introuvable plus d'accord.
Je préfère les appeler des boules de cheveux, mais +1
Bon code peut être un code rapide. Le problème peut être beaucoup de choses:
Je ne dirais pas que le code rapide est mort. Pour les contre-échantillons, consultez le code système d'exploitation (le planificateur O (1) de Linux »vous vient à l'esprit) et bien sûr du code de jeu.
Si vous êtes un fan de Winamp, vous aimerez peut-être lire cet excellent article sur Justin Frankel Les temps intéressants de l'AOL après AOL ont acheté Winamp.
Son dernier produit est Reaper .
L'optimisation a le plus de sens lorsque la plate-forme est corrigée pendant une longue période et que vous pouvez vraiment l'apprendre. Cela arrive toujours dans les jeux de console.
Après avoir écrit beaucoup de langage d'assemblage serré pour les jeux, je peux vous dire que cela prend du temps. Vous écrivez le même code encore et encore et modifiez vos structures de données, essayant d'obtenir un grand framerer.
Il n'y a plus de telle pression sur les applications PC. L'hypothèse est que le travail supplémentaire mis en place va rarement payer, que quiconque souhaite rapide achètera un ordinateur plus rapide.
Je ne connais aucun cas de courant dans lequel un bon compilateur ne produira pas de code rapide et efficace si donné du code source propre et bien écrit.
Maintenant, si vous utilisez une forme de générateur de code, cela dépendrait de la "bonté" de la sortie source du générateur. Certainement, dans le passé, j'ai vu des générateurs de code qui ont créé des tonnes et des tonnes de code à ordures pour des opérations apparemment simples. Je pense que les concepteurs d'outils souffrent de la maladie "tout et évier de cuisine". Les outils modernes doivent être plus maigres, mais il paie pour vérifier l'outil avant de plonger de gros dollars.
Encore une fois, si vous écrivez votre propre code, chaque compilateur que je suis au courant d'aujourd'hui prendra le bon, le code de nettoyage et créera des exécutables rapides et bien optimisés. (Sauf si vous désactivez toute l'optimisation des buts de débogage ou quelque chose comme ça).
acclamations,
-r
Les compilateurs sont géniaux, mais cela ne signifie pas qu'ils peuvent produire un code de foudre-rapide. Il prend encore du travail pour créer une application efficace avec les médias (DSP audio, vidéo, animation). Beaucoup de travail.
Je trouve de bonnes performances avec les bonnes structures de données, l'écriture d'algorithmes efficaces et ne pas faire plus travail est nécessaire et optimisant le code après avoir identifié les goulots d'étranglement utilisant des profileurs. Je ne trouve pas de bonnes performances est liée à la propreté de la propreté du code.
Un algorithme de merde sera lent, peu importe la façon dont "gee-wiz cool" le compilateur et parfaitement maintenu le code.
Dans mon expérience avec des logiciels non académiques, le plus gros tueur de performance est l'utilisation de nombreuses couches d'abstraction, chacune exige une pénalité de performance modeste, mais elle combine comme un intérêt composé. Chacun peut être considéré comme une "bonne chose" et la "façon recommandée de faire des choses", jusqu'à ce que vous voyiez le prix payé pour cela.
Vous voyez cela surtout dans des dessins axés sur les événements, où des choses à la recherche d'innocents comme définir une propriété ont un effet de cascade dans un réseau de classes.
Il est facile de confondre le code conçu sur le dessus avec le code clair. Le premier est souvent difficile à maintenir et peut produire des goulots d'étranglement énigmatiques. Mais le diagramme UML semble probablement vraiment soigné.
Je doute que la clarté du code est le problème avec le lecteur multimédia.
Bien que je pense que cela est peut-être une question intéressante de répondre, je trouve cela un peu perplexe que votre première devinez pourquoi une application est lente, c'est que les développeurs sont dus à la rédaction du code clair. :) En général, je pense que beaucoup de gens attribuent un «software BLOOAT» général (un terme plutôt ambigu) à la lenteur de certaines applications modernes.
Je ne veux pas dire, c'est la cause, mais partout (y compris StackoverFlow), quelqu'un demande, devrais-je utiliser ceci ou cela pour améliorer les performances? La réponse est presque toujours "non, ne vous souciez pas de la performance tant qu'il y ait un problème avec cela". Par conséquent, nous ne prenons la performance que comme un bogue, jamais comme une fonctionnalité ...
Je pense que beaucoup de programmeurs Stackoverflow font des applications commerciales, où vous devez avoir la maintenabilité. Autres programmeurs Stackoverflow Do Web, où le temps de marché est la clé. Les programmeurs de jeu sont toujours soucieux de la vitesse de code. Tout d'abord, vous le faites travailler, alors vous l'obtenez vite.
Avez-vous essayé d'exécuter les mêmes tests sous charge? Peut-être que "Media Player" remarque qu'il y a beaucoup plus de CPU disponible et tente de donner la lecture la plus riche possible?