Misskey (GeekNews) est un logiciel serveur de microblogging qui prend en charge la fédération ActivityPub. Misskey est principalement développé au Japon, et c’est une plateforme très appréciée des utilisateurs en quête de fonctionnalités ludiques, avec notamment les réactions par emoji, son propre langage de balisage MFM, le suivi de mots-clés (antennes), la décoration de profil, la création de pages interactives avec son langage de script maison AiScript, des mini-jeux, etc.
À ma connaissance, la stack technique de Misskey est la suivante. (Je peux me tromper.)
- NodeJS, TypeScript
- Koa.js, PostgreSQL, Redis
- Vue
Dans cet article, le mainteneur principal de Misskey, syuilo, vérifie les performances de Bun par rapport à NodeJS à partir du code source de Misskey.
- L’objectif est de tester si l’exécution du code existant tel quel avec Bun permet d’obtenir de meilleures performances. L’article précise qu’aucune optimisation spécifique pour Bun n’a été effectuée, et que les tests n’ont pas été menés lorsque le code incompatible était trop complexe.
- L’article demande aussi qu’on n’y voie qu’un simple cas d’étude.
- Les tests ont été réalisés sous Ubuntu, mais il est indiqué qu’il n’y avait pas de différence notable non plus sous Windows.
Pour aller droit à la conclusion, dans ce cas précis, on a surtout observé une baisse de performances avec Bun. La conclusion semble être qu’exécuter un grand codebase existant avec Bun ne le rend pas magiquement plus rapide. Voici le résumé généré par ChatGPT.
- Utilisation mémoire : Node environ 200MB, Bun environ 800MB, Bun consommant donc bien plus de mémoire.
- Vitesse d’exécution : sur divers traitements comme la consultation de timeline, Node a obtenu de meilleurs résultats. En particulier, pour la publication d’un post, Node a pris 5 secondes contre 10 secondes pour Bun, soit un Node 2 fois plus rapide.
- AiScript : pour l’exécution de code JavaScript pur, Node (moteur V8) est environ 1,5 fois plus rapide.
L’article présente des benchmarks d’exécution pour différentes parties du codebase, et à l’exception d’une exécution ponctuelle de WebSocket, NodeJS a été plus rapide dans tous les cas, parfois légèrement, parfois nettement. Même dans le cas de WebSocket, lors de 100000 exécutions, NodeJS a aussi montré un résultat légèrement meilleur.
Cela dit, l’auteur de l’article, syuilo, continue d’attendre beaucoup du potentiel d’évolution de Bun et mentionne aussi la possibilité d’améliorations de performances grâce à des optimisations supplémentaires.
9 commentaires
Dans les cas où on remplace simplement et on exécute, il existe aussi des cas encore peu optimisés, explicitement mentionnés dans la documentation ou les issues de bun, comme les bibliothèques liées à
node:cryptoou àzlib.Si, dans l’exemple, c’est devenu plus lent au point de passer de 5 à 10 secondes, je pense que c’est probablement lié à ce genre de points. En fait, j’ai moi aussi déjà eu ce problème avec une bibliothèque liée à JWT, où c’était devenu plusieurs fois plus lent, au point de devoir changer de bibliothèque pour l’optimiser.
Je me demande d’où vous tirez les articles des blogs techniques japonais. J’ai l’impression qu’ils sont structurés et vont à l’essentiel.
Je ne sais pas pour les autres articles, mais comme celui-ci a été publié sur Misskey, il pouvait être reçu sur le Fediverse (je l’y ai d’ailleurs vu d’abord avant de le voir repris ici).
Je ne connais pas bien la source de ce texte, mais il semble y avoir beaucoup de bons articles sur Qiita.
Il y a des personnes qui traduisent et publient sur plusieurs canaux des articles analysés sous un angle différent de celui des blogs anglophones ou coréens, et ils avaient en général un point commun : ils traduisaient des articles de Qiita.
Grâce aux suggestions de recherche de saisie semi-automatique de Google qui recommandaient de comparer Kita et Zenn, j’ai aussi pu découvrir Zenn. Merci pour l’information.
Qiita se prononce « Kita ».
Ah, d'accord, je vois...
C’est un résultat extrêmement intéressant. Dans le cas de Bun, ElysiaJS est souvent recommandé comme framework web, mais il y avait un problème de baisse de performances lorsqu’on n’utilisait pas l’API optimisée fournie par Bun. Il est indiqué que Koa.js a été utilisé, et on peut supposer que c’est de ce côté-là que les performances ont fortement chuté.
Il faut distinguer les différences entre le runtime et l’intégration au système.
Les performances dont Bun se vante proviennent globalement des caractéristiques de JSC, de certaines optimisations de l’intégration au système (ou de réductions de fonctionnalités) et du choix de bonnes bibliothèques de base.
C’est pourquoi, dans les benchmarks de petite taille, Bun a tendance à l’emporter, tandis que dans les benchmarks à grande échelle ou de longue durée, il a aussi tendance à être dépassé par Node.js.