Misskey (GeekNews) ist eine Microblogging-Server-Software mit Unterstützung für das ActivityPub-Fediverse. Misskey wird hauptsächlich in Japan entwickelt und ist eine Plattform, die vor allem von Nutzern geschätzt wird, die Spaß an vielen unterhaltsamen Funktionen haben, etwa Emoji-Reaktionen, dem eigenen Markup MFM, Keyword-Tracking (Antenna), Profil-Dekorationen, dem Erstellen interaktiver Seiten mit der eigenen Skriptsprache AiScript, Minispielen und mehr.
Soweit ich weiß, besteht der Tech-Stack von Misskey aus Folgendem. (Es kann sein, dass das nicht ganz stimmt.)
- NodeJS, TypeScript
- Koa.js, PostgreSQL, Redis
- Vue
In diesem Artikel prüft syuilo, der Maintainer von Misskey, anhand des Misskey-Quellcodes die Performance von Bun im Vergleich zu NodeJS.
- Ziel ist es zu testen, ob die bestehende Codebasis einfach durch das Ausführen mit Bun schneller wird. Im Artikel wird darauf hingewiesen, dass keine gesonderten Optimierungen für Bun vorgenommen wurden und Tests bei komplexen inkompatiblen Codepfaden nicht durchgeführt wurden.
- Der Artikel bittet darum, die Ergebnisse lediglich als einen einzelnen Fall zu betrachten.
- Getestet wurde unter Ubuntu, aber auch unter Windows habe es kaum Unterschiede gegeben.
Um es vorwegzunehmen: In diesem Fall überwogen unter Bun vielmehr Leistungseinbußen. Das Fazit scheint zu sein, dass eine große bestehende Codebasis nicht einfach magisch schneller wird, nur weil sie unter Bun läuft. Die von ChatGPT zusammengefassten Inhalte lauten wie folgt.
- Speicherverbrauch: Node etwa 200 MB, Bun etwa 800 MB, sodass Bun deutlich mehr Speicher verbraucht.
- Ausführungsgeschwindigkeit: Bei verschiedenen Verarbeitungen wie dem Abrufen der Timeline erzielte Node schnellere Ergebnisse. Besonders beim Erstellen eines Beitrags brauchte Node 5 Sekunden, Bun 10 Sekunden — Node war also doppelt so schnell.
- AiScript: Beim Ausführen von reinem JavaScript-Code war Node (V8-Engine) etwa 1,5-mal schneller.
Im Artikel sind Ausführungs-Benchmarks für einzelne Teile der Codebasis aufgeführt; mit Ausnahme einer einmaligen WebSocket-Ausführung zeigte NodeJS überall leicht oder teils deutlich bessere Ergebnisse. Selbst beim WebSocket-Fall war NodeJS bei 100.000 Durchläufen noch geringfügig schneller.
Allerdings erwartet der Autor syuilo weiterhin Entwicklungspotenzial bei Bun und erwähnt auch die Möglichkeit, dass sich die Leistung durch zusätzliche Optimierungen verbessern könnte.
9 Kommentare
Wenn man es einfach umstellt und laufen lässt, gibt es noch Fälle, die noch nicht gut optimiert sind, wie
node:crypto- oderzlib-bezogene Bibliotheken; das wird auch in der Bun-Dokumentation und in Issues ausdrücklich erwähnt.Wenn es wie in einem der Beispiele so stark langsamer wird, dass aus 5 Sekunden 10 Sekunden werden, liegt es vermutlich an so einem Bereich. Tatsächlich hatte ich wegen eines solchen Problems auch schon JWT-bezogene Bibliotheken, die um ein Mehrfaches langsamer wurden, sodass ich die Bibliothek wechseln und optimieren musste.
Ich würde gern wissen, woher Sie japanische Tech-Blogbeiträge beziehen. Sie wirken systematisch aufgebaut und auf das Wesentliche fokussiert.
Andere Artikel kenne ich nicht, aber da dieser auf Misskey gepostet wurde, konnte man ihn im Fediverse empfangen (ich habe ihn dort auch zuerst gesehen und dann gesehen, dass er hier gepostet wurde).
Ich kenne die Quelle dieses Textes zwar nicht genau, aber auf Qiita werden offenbar viele gute Artikel veröffentlicht.
Es gibt in mehreren Kanälen Leute, die Artikel übersetzen und posten, die aus einer anderen Perspektive analysiert sind als in anglophonen oder koreanischen Blogs; gemeinsam ist ihnen meist, dass sie Übersetzungen von Artikeln auf Qiita waren.
Dank der Google-Such-Autovervollständigung, die einen Vergleich zwischen Kita und Zenn als Suchbegriff vorgeschlagen hat, konnte ich auch Zenn finden. Vielen Dank für die Information.
Qiita spricht man als „Kita“ aus.
Ach so, verstehe. Wie peinlich.
Ein äußerst interessantes Ergebnis. Für Bun wird als Web-Framework häufig ElysiaJS empfohlen, doch wenn man nicht die von Bun bereitgestellte optimierte API verwendet, gab es vielmehr das Problem, dass die Performance sogar sank. Es heißt, dass Koa.js verwendet wurde; ich vermute, dass die Performance auf dieser Seite deutlich eingebrochen ist.
Man sollte den Unterschied zwischen Runtime und Systemintegration auseinanderhalten.
Die von Bun beworbene Performance beruht insgesamt auf den Eigenschaften von JSC, auf Optimierungen bei Teilen der Systemintegration (oder auf Funktionsreduktionen) sowie auf der Wahl guter Basisbibliotheken.
Deshalb neigt Bun in kleinen Benchmarks zwar dazu, zu gewinnen, während es in großen bzw. lang laufenden Benchmarks zugleich dazu neigt, hinter Node.js zurückzufallen.