Je pense que l'optimisation des performances intéresse de nombreux développeurs à mesure qu'ils en apprennent davantage sur les différentes façons d'accomplir une tâche. Une voix interne demande : « Quelle est la meilleure ? » Bien qu'il existe de nombreuses mesures changeantes pour le « meilleur », comme JavaScript : The Good Parts de Douglas Crockford en 2008, les performances sont accessibles car nous pouvons les tester nous-mêmes.
Cependant, tester et prouver les performances ne sont pas toujours faciles à réaliser.
Au début des années 2000, Internet Explorer avait remporté la première guerre des navigateurs. IE a même été le navigateur par défaut sur Mac pendant un certain temps. Netscape, autrefois dominant, a été vendu à AOL et a finalement été fermé. Leur spin-off Mozilla était en version bêta depuis des années pour leur nouveau navigateur autonome Phoenix Firebird Firefox.
En 2003, Opera 7 est sorti avec Presto, un nouveau moteur de rendu plus rapide. Apple a également publié Safari, un navigateur axé sur les performances pour Mac, construit sur le moteur peu connu Konqueror KHTML. Firefox a été officiellement lancé en 2004. Microsoft a publié IE 7 en 2006 et Opera 9 a publié un moteur JavaScript plus rapide. 2007 a introduit Safari sur Windows et sur le nouvel iPhone. 2008 a vu Google Chrome et le navigateur Android.
Avec davantage de navigateurs et de plateformes, les performances ont été un élément clé de cette période. Les nouvelles versions du navigateur annonçaient régulièrement qu'elles étaient le nouveau navigateur le plus rapide. Des références telles que SunSpider d'Apple et Kraken de Mozilla ont été fréquemment citées dans les versions et Google a maintenu sa propre suite de tests Octane. En 2010, l'équipe Chrome a même réalisé une série d'expériences de « tests de vitesse » pour démontrer les performances du navigateur.
Les tests de micro-performance ont suscité beaucoup d'attention dans les années 2010. Le Web passait d'une interactivité limitée sur la page à des applications entièrement côté client à page unique. Des livres comme High Performance JavaScript de Nicholas Zakas en 2010 ont démontré comment des choix de conception et des pratiques de codage apparemment minimes pouvaient avoir des impacts significatifs sur les performances.
Avant longtemps, la concurrence des moteurs JavaScript répondait à certains de ces problèmes de performances clés dans le JavaScript haute performance, et les changements rapides dans les moteurs rendaient difficile de savoir ce qui était le mieux à l'heure actuelle. Avec les nouvelles versions de navigateurs et la multiplication des appareils mobiles, les tests de micro-performances étaient un sujet brûlant. En 2015, le site de tests de performances jsperf.com, aujourd'hui fermé, était si populaire qu'il a commencé à avoir ses propres problèmes de performances dus au spam.
Avec l'évolution des moteurs JavaScript, il était facile d'écrire des tests, mais difficile de s'assurer que vos tests étaient équitables ou même valides. Si vos tests consomment beaucoup de mémoire, les tests ultérieurs peuvent entraîner des retards dans la récupération de place. Le temps de configuration a-t-il été compté ou exclu de tous les tests ? Les tests ont-ils même produit le même résultat ? Le contexte du test était-il important ? Si nous testions !~arr.indexOf(val) vs arr.indexOf(val) === -1, cela faisait-il une différence si nous exécutions simplement l'expression ou la consommons dans une condition if ?
Au fur et à mesure que les interpréteurs de script ont été remplacés par divers compilateurs, nous avons commencé à voir certains des avantages — et des effets secondaires — du code compilé : optimisations. Le code exécuté dans une boucle sans effets secondaires, par exemple, peut être complètement optimisé.
// Testing the speed of different comparison operators
for (let i = 0; i < 10000; i += 1) {
a === 10;
}
Comme il s'agit d'effectuer une opération 10 000 fois sans résultat ni effets secondaires, l'optimisation pourrait la supprimer complètement. Ce n'était cependant pas une garantie.
De plus, les micro-optimisations peuvent changer considérablement d'une version à l'autre. La malheureuse fermeture de jsperf.com a entraîné la perte de millions de comparaisons de tests historiques sur différentes versions de navigateur, mais c'est encore quelque chose que nous pouvons constater aujourd'hui au fil du temps.
Il est important de garder à l'esprit que les tests de performances de micro-optimisation comportent de nombreuses mises en garde.
Alors que les améliorations des performances commençaient à se stabiliser, nous avons vu les résultats des tests rebondir. Cela s'explique en partie par l'amélioration des moteurs, mais nous avons également vu des moteurs optimiser le code pour les modèles courants. Même si des solutions mieux codées existaient, les utilisateurs auraient un réel avantage à optimiser les modèles de code courants plutôt que d'attendre que chaque site apporte des modifications.
Pire que l'évolution des performances du navigateur, 2018 a vu des changements dans l'exactitude et la précision des minuteries pour atténuer les attaques d'exécution spéculative telles que Spectre et Meltdown. J'ai écrit un article séparé sur ces problèmes de timing, si cela vous intéresse.
Pour compliquer les choses, testez-vous et optimisez-vous le dernier navigateur ou le navigateur le moins pris en charge par votre projet ? De même, à mesure que les smartphones gagnaient en popularité, les appareils portables dotés d’une puissance de traitement nettement inférieure sont devenus des considérations importantes. Savoir où allouer son temps pour obtenir les meilleurs résultats – ou les résultats les plus percutants – est devenu encore plus difficile.
L'optimisation prématurée est la racine de tous les maux.
--Donald Knuth
Ceci est fréquemment cité. Les gens l'utilisent pour suggérer que chaque fois que nous pensons à l'optimisation, nous perdons probablement du temps et aggravons notre code au nom d'un gain imaginaire ou insignifiant. Cela est probablement vrai dans de nombreux cas. Mais il y a plus dans la citation :
Nous devrions oublier les petites efficacités, disons environ 97 % du temps : une optimisation prématurée est la racine de tous les maux. Pourtant, nous ne devons pas laisser passer nos opportunités dans ces 3 % critiques.
La citation plus complète ajoute un contexte critique. Nous pouvons consacrer beaucoup de temps à de petites gains d'efficacité si nous nous le permettons. Cela prend souvent du temps par rapport à l'objectif du projet sans apporter beaucoup de valeur.
J'ai personnellement passé beaucoup de temps sur ces optimisations, et sur le moment, cela ne m'a pas semblé être du gaspillage. Mais rétrospectivement, on ne sait pas exactement dans quelle mesure ce travail en valait la peine. Je suis sûr qu'une partie du code que j'ai écrit à l'époque a réduit de quelques millisecondes le temps d'exécution, mais je ne pouvais pas vraiment dire si le temps gagné était important.
Google parle même de rendements décroissants lors du retrait en 2017 de la suite de tests Octane. Je recommande fortement de lire cet article pour un aperçu approfondi des limitations et des problèmes d'optimisation des performances rencontrés par les équipes dédiées à ce travail.
Alors, comment pouvons-nous nous concentrer sur ces « 3 % critiques » ?
Comprendre comment et quand le code est utilisé nous aide à prendre de meilleures décisions sur les domaines sur lesquels nous concentrer.
Il n'a pas fallu longtemps avant que l'augmentation des performances et les variations des nouveaux navigateurs commencent à nous éloigner de ce type de micro-tests et à nous tourner vers des outils plus larges comme les flame charts.
Si vous disposez de 30 minutes, je vous recommande cette présentation Chrome DevSummit 2015 sur le moteur V8. Il parle exactement de ces problèmes... que les navigateurs ne cessent de changer, et suivre ces détails peut être difficile.
L'utilisation de la surveillance et de l'analyse des performances de votre application en cours d'exécution peut vous aider à identifier rapidement les parties de votre code qui s'exécutent lentement ou fréquemment. Cela vous met dans une excellente position pour examiner les optimisations.
L'utilisation d'outils et de bibliothèques de surveillance des performances vous permet de voir comment le code s'exécute et quelles parties doivent être modifiées. Ils nous donnent également la possibilité de voir si différents domaines nécessitent du travail sur différentes plates-formes ou navigateurs. Peut-être que localStorage est beaucoup plus lent sur un Chromebook avec une mémoire et un stockage eMMC limités. Peut-être avez-vous besoin de mettre en cache plus d’informations pour lutter contre un service cellulaire lent ou irrégulier. Nous pouvons deviner ce qui ne va pas, mais mesurer est une bien meilleure solution.
Si votre base de clients est suffisamment grande, vous pourriez bénéficier des outils de surveillance des utilisateurs réels (RUM), qui peuvent potentiellement vous permettre de savoir à quoi ressemble l'expérience client réelle. Ceux-ci sortent du cadre de cet article, mais je les ai utilisés dans plusieurs entreprises pour comprendre l'étendue de l'expérience client et concentrer les efforts sur les performances du monde réel et la gestion des erreurs.
Il est facile de se demander « comment puis-je améliorer cette chose », mais ce n'est pas toujours la meilleure réponse. Vous pouvez gagner beaucoup de temps en prenant du recul et en vous demandant : « Est-ce la bonne solution à ce problème ? »
Des problèmes de chargement d'une très grande liste d'éléments sur le DOM ? Peut-être qu'une liste virtualisée où seuls les éléments visibles sont chargés sur la page résoudrait le problème de performances.
Vous effectuez de nombreuses opérations complexes sur le client ? Serait-il plus rapide de calculer tout ou partie de cela sur le serveur ? Une partie du travail peut-elle être mise en cache ?
Prendre du recul : est-ce la bonne interface utilisateur pour cette tâche ? Si vous avez conçu une liste déroulante pour attendre vingt entrées et que vous en avez maintenant trois mille, vous avez peut-être besoin d'un composant ou d'une expérience différente pour faire une sélection.
Dans tout travail de performance, il y a une question secondaire : « qu'est-ce qui est suffisant » ? Il y a une excellente vidéo de Matt Parker de Stand-up Maths qui parle du code qu'il a écrit et de la façon dont sa communauté l'a amélioré de semaines d'exécution à millisecondes. Même s'il est incroyable qu'une telle optimisation ait été possible, il existe également un point pour presque tous les projets où vous atteignez "assez bien".
对于只运行一次的程序，几周可能是可以接受的，几个小时会更好，但你快速花费多少时间就成为一个重要的考虑因素。
您可能会认为它就像工程中的公差。我们有一个目标，我们有一个接受范围。我们可以追求完美，同时明白成功和完美并不相同。
目标是优化的关键部分。如果你只知道当前状态不好，“让它变得更好”就是一个开放式目标。如果没有优化之旅的目标，当您可以处理更重要的事情时，您可能会浪费时间尝试寻找更高的性能或更多的优化。
我对此没有一个好的衡量标准，因为性能优化可能会有很大差异，但尽量不要迷失在杂草中。这实际上与项目管理和规划有关，而不仅仅是编码解决方案，但在定义优化目标时，开发人员的输入非常重要。正如“替代方案”部分中所建议的，解决方案可能不是“使其更快”。
就马特·帕克的情况而言，他最终需要答案，并且不需要将该设备用于其他任何用途。在我们的世界中，我们经常衡量访问者表现及其可能的财务影响与开发人员/团队时间以及您的机会成本，所以措施没那么简单。
假设我们知道将添加到购物车的时间减少 50% 将使我们的收入增加 10%，但完成这项工作需要两个月的时间。有什么比两个月的优化工作产生更大的财务影响吗？你能在更短的时间内实现一些效益吗？再说一次，这是关于项目管理而不是代码。
当您确实发现自己需要优化代码时，也是看看是否可以将该代码与项目的其他部分分开的好时机。如果您知道必须编写复杂的优化，这将使代码难以理解，那么将其提取到实用程序或库可以使其更容易重用，并允许您在需要随时间变化时在一个地方更新该优化。
表演是一个复杂的话题，有很多曲折。如果你不小心的话，你可能会投入大量的精力却收效甚微。好奇心可以是一位好老师，但它并不总是能取得成果。玩弄代码性能是有好处的，但也有时间分析项目中缓慢的实际来源并使用可用的工具来帮助解决它们。
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!
Introduction à l'utilisation du code complet VBS
Comment faire fonctionner json avec jquery
Comment utiliser la commande scannow
Windows ne peut pas accéder à l'ordinateur partagé
Comment taper le symbole inférieur ou égal dans Windows
BatterieMon
Java exporter Excel
Introduction aux caractères de retour chariot et de saut de ligne en Java
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
