Misskey (GeekNews) es un programa de servidor de microblogging que admite federación con ActivityPub. Misskey se desarrolla principalmente en Japón y es una plataforma muy buscada por usuarios que quieren divertirse, ya que incluye muchas funciones entretenidas como reacciones con emojis, su propio marcado MFM, seguimiento de palabras clave (antenas), decoración de perfiles, creación de páginas interactivas con su propio lenguaje de scripts AiScript, minijuegos y más.
Hasta donde sé, el stack tecnológico de Misskey es el siguiente. (Podría estar equivocado.)
- NodeJS, TypeScript
- Koa.js, PostgreSQL, Redis
- Vue
En este artículo, syuilo, el mantenedor principal de Misskey, verifica el rendimiento de Bun frente a NodeJS usando el código fuente de Misskey.
- El objetivo es probar si el código existente se vuelve más rápido al ejecutarlo tal cual en Bun. El artículo aclara que no se realizaron optimizaciones específicas para Bun y que, si el código incompatible era complejo, no se hicieron pruebas.
- El texto pide que se tome únicamente como un caso de referencia.
- Las pruebas se hicieron en Ubuntu, pero se comenta que en Windows tampoco hubo grandes diferencias.
Yendo directo a la conclusión, en este caso predominó más bien una degradación del rendimiento en Bun. Parece que la conclusión es que ejecutar una base de código grande existente en Bun no la vuelve mágicamente más rápida. Esto es lo que resumió ChatGPT.
- Uso de memoria: Node alrededor de 200MB, Bun alrededor de 800MB, por lo que Bun consume mucha más memoria.
- Velocidad de ejecución: en varios procesos, como la consulta de timeline, Node registró mejores resultados. En particular, al publicar una entrada, Node tardó 5 segundos y Bun 10 segundos, así que Node fue 2 veces más rápido.
- AiScript: en ejecución de código JavaScript puro, Node (motor V8) fue aproximadamente 1.5 veces más rápido.
El artículo incluye benchmarks de ejecución para cada parte de la base de código, pero salvo en una ejecución única de WebSocket, en todos los casos NodeJS mostró resultados más rápidos, ya sea por poco o por bastante. Incluso en el caso de WebSocket, al ejecutarlo 100 mil veces, NodeJS también mostró un resultado ligeramente mejor.
Aun así, el autor del artículo, syuilo, sigue esperando el potencial de evolución de Bun y también menciona la posibilidad de que el rendimiento mejore con optimizaciones adicionales.
9 comentarios
En casos donde simplemente se reemplaza y se ejecuta, también hay casos que aún no están bien optimizados, como las librerías relacionadas con
node:cryptoozlib, algo que incluso está indicado en la documentación y en los issues de Bun.Si en el ejemplo se volvió lo bastante lento como para pasar de 5 segundos a 10 segundos, probablemente se deba a algo de este tipo. De hecho, a mí también me pasó que una librería relacionada con JWT se volvió varias veces más lenta por este problema, así que tuve que cambiar la librería para optimizarlo.
Me da curiosidad saber de dónde sacan los artículos de blogs técnicos en japonés. Se sienten estructurados y con puntos clave.
No sé sobre los otros artículos, pero como este se publicó en Misskey, se pudo recibir en el fediverso (yo también lo vi primero ahí y luego vi que lo publicaron aquí).
No conozco bien la fuente de este texto, pero parece que en Qiita se publican muchos buenos artículos.
Hay personas que traducen y publican en varios canales artículos analizados desde una perspectiva distinta a la de los blogs angloparlantes o coreanos, y en general tenían en común que habían traducido textos de Qiita.
Gracias a que la función de autocompletar de la búsqueda de Google me sugirió un término para comparar Kita y Zenn, también pude encontrar Zenn. Gracias por la información.
Qiita se pronuncia Kíta.
Ah, ya veo, qué pena.
Es un resultado muy interesante. En el caso de Bun, suele recomendarse mucho ElysiaJS como framework web, pero existía el problema de que, si no se usaban las API optimizadas que ofrece Bun, el rendimiento más bien empeoraba. Dice que usaron Koa.js, así que supongo que el rendimiento cayó bastante por ese lado.
Hay que distinguir entre las diferencias del runtime y las de la integración con el sistema.
El rendimiento del que presume Bun, en general, proviene de las características de JSC, de la optimización de parte de su integración con el sistema (o de la reducción de funcionalidades) y de la elección de buenas bibliotecas base.
Por eso, en benchmarks pequeños Bun tiende a ganar, pero al mismo tiempo en benchmarks a gran escala o de larga duración tiende a quedar por detrás de Node.js.