Je pense que cette capture d'écran d'une mesure réellement existante de la productivité est suffisante pour transmettre le sens de l'article, mais si le lecteur est intéressé par mes réflexions à ce sujet, alors bienvenue.
Les programmeurs sont obsédés par la vitesse d'exécution du programme. Nous surveillons la vitesse même lorsque cette vitesse n'est pas très importante. Parfois contraire au bon sens et à la logique. Ne comprenant même pas complètement ce que les mots «vitesse» ou «performance» signifient vraiment dans chaque cas. Nous voulons toujours le matériel le plus rapide, le langage le plus rapide et le framework le plus léger.
Volontiers, je crois que vous, nom d'utilisateur, n'êtes pas comme ça. Que vous êtes vous-même capable d'écrire le bon benchmark, vous savez comment fonctionne tel ou tel runtime, vous détestez l'optimisation de la vitesse uniquement pour l'optimisation de la vitesse et vous en savez beaucoup sur le matériel. Mais il y a plus de gens du paragraphe précédent. Vérifié.
En voyant l'exemple dans l'image ci-dessus, j'ai d'abord étouffé avec du café ...
- Comment le tapuscrit peut-il fonctionner plus rapidement que le javascript, tout en consommant plusieurs fois moins de mémoire?!
- Pas question!
Typescript n'a pas son propre runtime. C'est-à-dire que vous ne pouvez pas exécuter dactylographié n'importe où ou presque n'importe où. Vous devez d'abord le compiler en javascript, qui s'exécute ensuite en runtime, ce que tout javascript comprend. Dans ce cas, le nœud v11.3434 a agi comme un tel runtime. Par une heureuse coïncidence, l'exemple javascript s'exécute également sur le même runtime.
Au lieu de comparer les langues, nous obtenons une micro-compétition dans la programmation sportive.
→ code tapuscrit
→ code javascript
Il s'avère que le temps d'exécution, la consommation de mémoire et d'autres caractéristiques dépendent de manière critique de qui a écrit ce code de vérification et comment. Bien sûr, ici, vous pouvez saisir l'argument selon lequel le dactylographe vous oblige à écrire "le bon code". Mais personne ne prend la peine de compiler du texte dactylographié en javascript, et je n'ai pas non plus vu d'endroits avec des optimisations.
Au fait, depuis combien de temps avez-vous vu quelqu'un écrire un code similaire, et il a fait l'objet d'un examen? Solid, OOP et FP ne sentent pas ici. Le code est écrit explicitement dans un style procédural. Parce qu'il a une tâche différente. Bien comprendre, même si le code résout le problème, il nécessite une refactorisation avant la production. Et on ne sait pas comment le refactoring affectera les performances. Mais c'est probablement une pioche.
Nous avons trouvé un exemple. De toute évidence, l'exemple est insuffisant.
Mais voyons comment d'autres langages de programmation ont réussi le même test.
Que pensez-vous, est-il juste de conclure que Swift est plus rapide que Go? Je pense que c'est faux. Il suffit de voir que deux implémentations Rust (lignes 2 et 6) diffèrent dans le temps par 2 fois.
Et ici, le problème semble déjà plus grave. Si la comparaison de dactylographie et de javascript est considérée comme une blague, alors dans le cas d'autres langues, le problème n'est pas si évident. Et pourriez-vous commencer à comprendre quel était le problème si vous voyiez un tel rapport?
Il s'avère que le code de référence doit être étroitement surveillé.
Question: À quand remonte la dernière fois que vous avez vu une personne qui tente de revérifier la façon dont le code de référence est écrit juste après avoir vu de beaux graphiques de performances standard?
Je les rencontre très rarement. Je pense que ces ingénieurs sont très peu nombreux.
D'un autre côté, sous mes yeux, il existe de nombreux exemples où, sur la base de ces tests, une conclusion est tirée sur les performances et la légèreté de la technologie. Et, soit dit en passant, l'opinion publique se forme.
Ici, vous pouvez comparer les performances des principaux frameworks javascript.
Faites-vous toujours confiance aux résultats? Non.
C’est tout. Mais il y a de bonnes nouvelles. La compétence du programmeur est toujours une influence majeure sur la performance du programme.
Conclusion:
Les Microbenchmarks ne vous montreront rien sauf si vous êtes professionnel en performance pour une plate-forme particulière. Mieux encore, vous rédigez vous-même ces repères en tenant compte exactement de vos exigences et conditions, tout en comprenant ce que vous faites.
PS:
Le message est écrit comme une réponse à des comparaisons et des conclusions hâtives sur la productivité future. Bien sûr, toutes les conclusions et les arguments de l'article peuvent être donnés sans cet exemple, mais avec des chiffres et des détails, c'est plus amusant et clair.