Conclusion principale
- Le langage Go n’est pas toujours plus rapide. Au contraire, un runtime JS peut parfois être plus rapide.
- Go se distingue par sa simplicité et son efficacité, mais dans des conditions réelles, ses performances peuvent parfois être inférieures aux attentes.
- En particulier, dans les situations avec beaucoup d’I/O base de données, ses performances peuvent être inférieures à celles d’un runtime JavaScript comme Bun.
Résultats du benchmark
- Go a montré un débit de requêtes plus élevé et une consommation mémoire plus faible, mais son utilisation CPU était 2 à 3 fois plus élevée.
- Cependant, dans un environnement réel avec beaucoup d’I/O DB, Bun (avec la combinaison du framework Elysia et de la bibliothèque MySQL2) a montré des performances plus stables et plus efficaces.
- Le routeur HTTP standard avait des performances faibles, et après être passé au framework Fiber, des temps de réponse comparables à ceux de Bun ont été obtenus. (N’utilisez pas le routeur HTTP standard de Go !)
Ce benchmark m’a amené à réfléchir aux points forts de Go
- Le fait qu’il offre divers types primitifs et la sûreté de typage.
- Déploiement en binaire unique : possibilité de déployer avec un simple exécutable, sans dépendance à un runtime.
- Goroutines : prise en charge efficace du traitement parallèle, permettant de tirer au mieux parti du matériel lorsqu’elles sont bien utilisées.
Limites ressenties lors de ce benchmark et pistes d’amélioration
- Problème de performance suspecté du driver MySQL : le
go-mysql-driver de Go est stable mais lent, et semble moins performant que mysql2 en JavaScript. (Bien sûr, je peux aussi me tromper.)
- Pour les tâches sans connexion DB, Go montre de meilleures performances. C’est peut-être tout simplement normal.
- Faibles performances du routeur HTTP : pour votre santé mentale, utilisez Fiber ou un autre framework !
Pourquoi continuer à utiliser Go malgré cette déception côté performances
- La sûreté de typage de Go, le déploiement en binaire unique et les performances parallèles des goroutines restent très attractifs pour un développeur. Des types que TypeScript ne peut pas offrir, ainsi qu’un déploiement en fichier binaire unique sans avoir besoin de
npm install, ont été de très gros avantages.
- En voyant qu’il existe encore des possibilités d’optimisation supplémentaires, j’ai décidé de continuer à apprendre et à utiliser Go.
Message aux développeurs
- Tous les langages et toutes les technologies ont leurs avantages et leurs inconvénients. Je pense que c’est aussi le cas de Go.
- Plutôt que d’être déçu par les performances de Go, il serait bon de bien exploiter ses points forts et de continuer à chercher des moyens de dépasser ses limites de performance.
- J’ai écrit ce billet pour partager avec les développeurs qui utilisent Go qu’il existe aussi ce type de résultats d’analyse.
16 commentaires
C’est complètement hors sujet, mais la police IBM Plex Sans KR est vraiment magnifique.
J’aimais vraiment beaucoup cette police aussi et je l’ai utilisée, mais il y a juste un petit point regrettable : sur un écran à faible résolution, elle n’est pas particulièrement jolie. Haha, en revanche sur un moniteur 5K, elle est vraiment magnifique !
Je pense qu’il faut vraiment faire très attention quand on critique quelque chose.
On ne sait pas clairement s’il s’agit d’un problème au niveau du langage, d’une bibliothèque en particulier ou du code lui-même, et affirmer publiquement que quelque chose n’est pas bon sans fournir suffisamment d’informations pour que d’autres puissent le reproduire
n’est probablement pas quelque chose d’agréable à entendre pour les personnes qui vivent dans cet écosystème, même si telle n’était pas votre intention.
Bonjour, et merci d’avoir pris le temps de laisser un avis aussi précieux. Je comprends dans quel état d’esprit vous avez écrit votre commentaire, et si jamais mes propos ont pu donner l’impression que je critiquais l’avenir de Go ou ses utilisateurs, ce n’était pas du tout mon intention ; je tiens à le redire une fois encore et à m’en excuser. Et si cela vous convient, je pense que si vous cliquez sur le titre de l’article, vous y trouverez plusieurs données ainsi qu’un autre billet de blog écrit par quelqu’un d’autre ; c’est un peu long, mais si vous le lisez, vous pourrez sans doute comprendre plus clairement mon intention.
J’ai tendance à voir les langages comme une sorte de voiture. Chaque voiture a ses avantages et ses inconvénients, son coût d’acquisition, et même si elles semblent remplir le même rôle, elles poursuivent en réalité des valeurs différentes ; c’est en cela que je trouve la comparaison pertinente. Bien sûr, je pense aussi qu’il est tout à fait naturel d’éprouver un attachement particulier pour un véhicule et d’aimer sa voiture. Moi aussi, j’aime ma voiture et j’ai confiance dans son constructeur.
Malgré cela, moi aussi j’ai des points qui me déçoivent ou me frustrent dans ma voiture, et les testeurs qui passent régulièrement les modèles automobiles en revue partagent toujours leurs analyses en les comparant aux modèles concurrents sous différents angles. Si quelqu’un dit que la boîte de vitesses de ma voiture n’est pas terrible, ou que sa consommation n’est pas bonne, je ne peux pas dire que cela me fasse plaisir. Malgré tout, j’essaie de faire la distinction entre la voiture et moi en tant que conducteur. J’essaie aussi d’en apprendre davantage sur la voiture que je conduis, que ce soit sur ses qualités ou sur ses défauts. Peut-être que je conduirai une autre voiture un jour, mais l’expérience de conduite actuelle me sera utile à ce moment-là aussi.
Je n’ai pas pu trop le mentionner dans la version résumée, mais dans le corps de l’article de blog, je concluais en disant que malgré les points décevants de Go, ses avantages restent plus nombreux et que j’ai donc l’intention de continuer à l’utiliser (= à le conduire). Comme chaque langage poursuit des valeurs et présente des atouts différents, j’essaie pour ma part d’en utiliser le plus possible de variés (= différents véhicules). C’est aussi la raison pour laquelle j’envisage de quitter un runtime JS que j’utilisais bien pour passer volontairement à Go.
J’avais le sentiment d’avoir rédigé l’article avec autant de soin que possible pour éviter des guerres de chapelle inutiles entre langages, mais s’il y a malgré tout des Gophers que cet article a pu indisposer, j’espère encore une fois qu’ils accepteront de me pardonner, et je terminerai ce commentaire en précisant que je suis aussi un codeur romantique qui aime même PHP, ce langage qui s’est tant fait critiquer !
Dans l’article original, l’auteur expose sa propre analyse des parties lentes ainsi que les raisons pour lesquelles il utiliserait quand même Go. J’ai donc du mal à comprendre pour quelle raison vous avez interprété ce texte comme un jugement de valeur.
C’est anecdotique, mais les bibliothèques standard de Go voient leurs performances diminuer avec le temps. La raison principale est le compromis lié aux nombreuses vulnérabilités de sécurité signalées, à mesure que diverses fonctionnalités sont ajoutées pour respecter les standards RFC.
Récemment, pour obtenir la certification FIPS, on s’attend même à ce que la perte de performances augmente encore un peu.
Dans ce contexte, écarter tous ces éléments de fond et se contenter d’écrire qu’« dans le scénario le plus simple et le plus spécifique, les performances sont mauvaises » me semble largement suffisant pour induire beaucoup de gens en erreur, hélas.
J’attends la version 1.0 de tsboard avec impatience haha
Merci d’avoir patienté ! Je vais m’y mettre avec plaisir haha
J’ai l’impression qu’il n’y a pas vraiment de raison que JS soit lent puisqu’il utilise le JIT.
À part le multithreading, la stabilité, etc.
C’est aussi quelque chose que j’ai découvert de nouveau grâce à ce benchmark, et je pense pouvoir dire sans trop m’avancer que, côté stabilité, il n’y a pas non plus de problème majeur. Il est vrai que le multithreading nécessite clairement de l’orchestration, donc c’est un peu contraignant.
Le site est inaccessible chez moi aussi, ou je suis le seul ?
Bonjour ! Merci de me l’avoir signalé en commentaire haha. Je n’ai pas encore pu migrer le site vers un hébergement, donc il peut parfois y avoir des problèmes d’accès. Je vais faire le nécessaire pour régler ça dès que possible. (Pour l’instant, c’est un mini PC à la maison qui fait tout le boulot 😂)
Oh, maintenant ça fonctionne. Je vais le lire attentivement !
J’ai déplacé le site de mon mini-PC maison vers un serveur virtuel de la taille d’un studio... ! Aujourd’hui, beaucoup plus de personnes que prévu sont passées au cours de la journée avant de devoir repartir, mais je vous annonce que le problème est désormais réglé !
Je me demande si on obtiendrait des résultats différents en faisant l'expérience avec le pilote
github.com/jackc/pgx/v5et PostgreSQL.Je me demande aussi si ce résultat est limité à MySQL, ou s’il s’applique à tous les scénarios utilisant une base de données. Je pense que d’autres partageront leurs résultats un jour ou l’autre, haha.