Les gars qui ont écrit Brespin (éditeur de code basé sur une toile en nuage [et plus]) ont récemment parlé de la manière dont ils ont réaffirmé et optimiser une partie du code BESPIN en raison d'une idée fausse que JavaScript était lent. Il s'est avéré que lorsque tout a été dit et fait, leur optimisation n'a produit aucune amélioration significative.
Je suis sûr que beaucoup d'entre nous sortons de notre façon d'écrire un code "optimisé" basé sur des idées fausses similaires à celles de l'équipe BESPIN.
Quelles sont des concepteurs fausses de mauvaise qualité de performances communes qui sont couramment souscrives à?
8 Réponses :
Et c'est ce qui se passe quand on optimise sans un profil valide en main. Tout ce que vous faites sans profil ne devine et probablement gaspiller du temps et de l'argent. Je pourrais énumérer un groupe d'autres idées fausses, mais beaucoup se passent au fait que si le code en question n'est pas un consommateur de premier ordre, c'est probablement bien. Un peu comme déroulement A pour la boucle qui fait du disque I / O ...
Certainement la plus grande idée fausse - vous pensez savoir pourquoi il est lent. Profil, profil, profil!
Le mot clé est ici valide . Assurez-vous que le test de performance que vous utilisez pour identifier les goulots d'étranglement ressemble à la charge de production.
et, sans rapport:
Certaines personnes, lorsqu'elles sont confrontées à un problème, pensez-moi "que je sais, je vais utiliser des expressions régulières." Maintenant, ils ont deux problèmes.
-jwz
Enfer, cette réponse n'était pas ici quand j'ai écrit le mien! MDR. : DDD
Et la chose la plus amusante est que nos deux réponses ont été aussi perçues: d.
Si je convertissez la base de code entière sur [Insérer la dernière technologie XXX ici], ce sera beaucoup plus rapide.
Cette idée fausse est beaucoup plus souvent tenue par les PHB que par les programmeurs eux-mêmes. Devinez qui fait la décision ...
Pouvez-vous développer Rotfllollmao pour nous?
soupir. Je sais rotflmao. Quelle est la partie "llol" au milieu? Ou est-ce "LOLL"? :-)
R.Loling O.N T.HE F.LOOR L.UGHING O.UT L.oud L.aughing M.y A.SS O.FF Je pense que Rotflmao aurait plus de sens. :-)
Mes règles d'optimisation.
Ma meilleure optimisation a réduit un rapport de 3 jours à 9 minutes. Le code optimisé a été accéléré de trois jours à trois minutes.
Dans mon carrière, j'ai rencontré trois personnes chargées de produire un tri plus rapide sur VAX que le type natif. Ils avaient été invariablement capables de produire des sortes qui n'ont pris que trois fois plus longtemps.
Dans aucun ordre particulier:
"prêt, incendie, but" - pensant que vous savez ce qui doit être optimisé sans le prouver (c'est-à-dire deviner ), puis agissant à ce sujet, et puisque ça ne fait pas Il aide beaucoup à supposer que le code doit avoir été optimal pour commencer.
hotspot - quelle est la définition? J'en ai un: c'est une région d'adresses physiques où le registre PC est trouvé une fraction de temps importante. C'est le genre de chose que les échantillonneurs PC sont bons à la recherche. De nombreux problèmes de performance exposent des points chauds, mais uniquement dans les programmes les plus simples, c'est le problème au même endroit que le hotspot est .
goulot d'étranglement - une trace-tout à terme utilisé pour les problèmes de performance, cela implique un canal limité contraignant la manière dont le travail rapide peut être accompli. L'hypothèse non déclarée est que le travail est nécessaire. Dans mes décennies de réglage de la performance, j'ai en fait trouvé quelques problèmes comme ça - très peu. Presque tous sont de nature très différente. Plutôt que de prendre la route la plus courte du point A à B, de petits détours sont pris, sous la forme d'appels de fonction qui prennent peu de code, mais pas peu de temps. Ensuite, ces détours prennent d'autres détours imbriqués, parfois 30 niveaux profonds. Plus les détours sont imbriqués, plus il est probable que certains d'entre eux sont moins que nécessaires - gaspillés, en fait - et il se produit presque toujours de généralité galopant - incontestion sur-indulgence dans "abstraction" .
profileur - une bonne chose universelle, non? Tout ce que tu dois faire, c'est obtenir un profileur et faire du profilage, non? JAMAIS Pensez à quel point il est facile de tromper un profileur pour vous dire beaucoup de rien, lorsque votre objectif est de savoir ce que vous devez corriger pour obtenir une meilleure performance? Quelque part dans votre arbre d'appels, rentrez un petit fichier E / S, ou un petit appel à une routine système, ou faites-le votre diabolique. À un moment donné, ce sera votre problème et la plupart des profileurs le manqueront complètement parce que la seule inefficacité qu'ils contemplent est l'inefficacité algorithmique . Ou, toutes vos routines ne seront pas peu nombreuses, et elles ne peuvent pas appeler une autre routine dans un petit nombre d'endroits, votre graphique de votre appel dit qu'il y a un lien entre les deux routines, mais quel appelez ? Ou supposons que vous puissiez comprendre que quelque chose de grand pourcentage est passé dans un chemin d'accès aux appels b appelle C. Vous pouvez considérer cela et penser qu'il n'y a pas grand chose à faire à ce sujet, lorsque vous pouviez également regarder les données passées Dans ces appels, vous pourriez voir s'il est nécessaire. Voici un projet amusant - choisissez votre profileur préféré, puis voyez combien de façons que vous pourriez le tromper. C'est-à-dire que trouver des moyens de faire du programme plus longtemps sans que le profileur ne soit capable de dire ce que vous avez fait, car si vous pouvez le faire intentionnellement, vous pouvez également le faire sans intention.
mesure - (c'est-à-dire mesurer temps ) C'est ce que les profileurs ont fait depuis des décennies et ils sont fiers de la précision et de la précision avec lesquelles elles mesurent. Mais mesurez-vous qu'est-ce que temps? et pourquoi avec précision? N'oubliez pas que l'objectif est de localiser avec précision les problèmes de performance , de telle sorte que vous puissiez les optimiser de manière fructueuse pour gagner une vitesse d'accélération. Lorsque vous obtenez ce speedUp, c'est ce que c'est, peu importe la manière dont vous avez préalablement estimé. Si cette précision de mesure est achetée au détriment de la précision de l'emplacement, vous venez d'acheter des pommes lorsque vous aviez besoin d'oranges.
++ i vs. code > i ++ pendant que les montagnes du temps sont consacrées sans inutilement dans des conceptions trop transmises, en particulier des structures de données et des bases de données.
Hmmm, les profileurs ont été très utiles pour moi et j'ai apporté des améliorations grâce à elles à la fois mesurable et perceptible ... Je n'ai pas vraiment votre point.
@ALEX: Oui, ils trouvent certains problèmes . Savez-vous que vous n'avez pas eu plus de possibilités d'accélération? L'absence de preuve n'est pas une preuve d'absence. Voici un exemple de ce que je veux dire, où sur plusieurs itérations, une accélération de plus de 40 fois a été démontrée: Stackoverflow.com/questions/926266/...
+1, bien que je ne suis pas d'accord avec (ou mal compris) la partie "goulot d'étranglement". Mon point de vue: le goulot d'étranglement décrit la composante matérielle qui limite - par exemple. CPU, cache, disque. Lors de l'exécution d'un programme de calcul de calcul, tous les composants sont rarement à leurs limites - généralement, un goulot d'étranglement sera le goulot d'étranglement. Vous pouvez réduire la charge globale, vous pouvez supprimer la "pression" d'un composant de sorte qu'il ne fait pas de goulot d'étranglement si tôt, et vous pouvez déplacer la "pression" entre les composants.
@peterchen: Tu as raison. Mon boeuf est que le terme est généralement appliqué à tout ce qui fait que les logiciels prennent plus de temps qu'il ne le devrait, et comme une métaphore, il est trompeur. Cela implique que le cheval de course est limité par la rapidité de ses jambes (par exemple). Bien sûr, mais le problème très typique du logiciel non jouet est que plutôt que de courir droit, le cheval suit une côte fractale de détours imbriqués, beaucoup d'entre eux pas vraiment nécessaires. Je souhaite qu'il y ait une meilleure métaphore pour capturer cette idée, car les gens ne sont pas vraiment conscients de cela.
@peterchen: Peut-être une autre façon de dire que nos appels peuvent devenir beaucoup trop propulsés et avoir besoin de taille. Quel est un mot pour cela? "Code de Kudzu" Peut-être?
Merci pour vos commentaires - je suis d'accord. Compilateurs et esp. Le matériel a fait incroyable progrès dans le traitement de Kudzu (devait le chercher!) Cependant, la croissance semble toujours une puissance légèrement supérieure à celle des gains. Toujours: de plus en plus pour élaguer
Les règles sont simples:
"Cela doit être aussi rapide que possible."
Si vous n'avez pas de problème de performance, vous n'avez pas besoin de vous soucier de l'optimisation des performances (au-delà, faites simplement attention à l'utilisation de bons algorithmes).
Cette idée fausse se manifeste également dans les tentatives d'optimisation des performances pour chaque aspect de votre programme. Je vois cela le plus souvent avec des personnes qui tentent de raser chaque dernier milliseconde du temps d'exécution d'une application Web à faible volume tout en ne prenant en compte que la latence de réseau prendra des ordres de grandeur plus longs que le temps d'exécution de leur code, en faisant une réduction de temps d'exécution. non pertinent de toute façon.