Misskey (GeekNews) é um programa de servidor de microblog com suporte à federação ActivityPub. O Misskey é desenvolvido principalmente no Japão e oferece muitos recursos divertidos, como reações com emoji, seu próprio markup chamado MFM, rastreamento de palavras-chave (Antena), decoração de perfil, criação de páginas interativas com sua linguagem de script própria, AiScript, minijogos e muito mais, o que faz com que seja uma plataforma bastante procurada por usuários em busca de diversão.
Pelo que eu sei, a stack tecnológica do Misskey é a seguinte. (Posso estar errado.)
- NodeJS, TypeScript
- Koa.js, PostgreSQL, Redis
- Vue
Neste artigo, syuilo, mantenedor principal do Misskey, verifica o desempenho do Bun em comparação com o NodeJS usando o código-fonte do Misskey.
- O objetivo é testar se ele fica mais rápido ao executar o código existente no Bun sem alterações. O texto deixa claro que não foram feitas otimizações específicas para o Bun e que, quando o código incompatível era complexo, o teste não foi realizado.
- O artigo ressalta que isso deve ser visto apenas como um único caso.
- Os testes foram feitos no Ubuntu, mas foi dito que no Windows também não houve grande diferença.
Indo direto à conclusão: neste caso, o comportamento predominante foi, na verdade, uma piora de desempenho no Bun. A conclusão parece ser que executar um grande código existente no Bun não o torna magicamente mais rápido. Eis o resumo feito pelo ChatGPT.
- Uso de memória: Node cerca de 200MB, Bun cerca de 800MB; o Bun consome muito mais memória.
- Velocidade de execução: em vários processamentos, como consulta de timeline, o Node registrou resultados melhores. Em especial, ao criar uma postagem, o Node levou 5 segundos e o Bun 10 segundos, tornando o Node 2 vezes mais rápido.
- AiScript: na execução de código JavaScript puro, o Node (motor V8) foi cerca de 1,5 vez mais rápido.
O artigo traz benchmarks de execução para cada parte da base de código, mas, com exceção de uma execução única de WebSocket, em todos os casos o NodeJS apresentou resultados mais rápidos, por pequena ou grande margem. Mesmo no caso do WebSocket, ao executar 100 mil vezes, o NodeJS também mostrou um resultado ligeiramente melhor.
Ainda assim, o autor do texto, syuilo, continua esperando o potencial de evolução do Bun e também menciona a possibilidade de melhora no desempenho com otimizações adicionais.
9 comentários
Em casos em que apenas se troca e roda, ainda há situações menos otimizadas, como bibliotecas relacionadas a
node:cryptoouzlib, algo que também está explicitamente indicado na documentação e nas issues do Bun.Se, como no exemplo, ficou mais lento a ponto de ir de 5 segundos para 10 segundos, imagino que provavelmente seja por causa de algo assim. Na prática, eu também já tive um caso em que isso deixou uma biblioteca relacionada a JWT várias vezes mais lenta, então precisei trocar a biblioteca e otimizá-la.
Fiquei curioso sobre de onde vocês obtêm os posts de blogs técnicos em japonês. A impressão é de que são bem estruturados e focados nos pontos principais.
Não sei quanto aos outros textos, mas como este foi publicado no Misskey, foi possível recebê-lo pelo fediverso (eu também o vi primeiro por lá e depois vi que tinha sido postado aqui)
Não sei ao certo qual é a fonte deste texto principal, mas parece que muitos bons artigos são publicados no Qiita.
Há pessoas que traduzem e publicam, em vários canais, textos analisados sob perspectivas diferentes das de blogs do mundo anglófono ou da Coreia, e em geral todos tinham em comum o fato de serem traduções de artigos do Qiita.
Consegui encontrar o zenn também porque o preenchimento automático da Busca do Google sugeriu um termo de pesquisa comparando Kita e zenn. Obrigado pela informação.
Qiita se lê como Kíta.
Ah, entendi. Que vergonha.
É um resultado extremamente interessante. No caso do Bun, o ElysiaJS é frequentemente recomendado como framework web, mas havia o problema de que, se você não usasse as APIs otimizadas fornecidas pelo Bun, o desempenho acabava sendo pior. Está escrito que foi usado o Koa.js, então é provável que a performance tenha caído bastante por esse lado.
É preciso distinguir a diferença entre o runtime e a integração com o sistema.
O desempenho que o Bun divulga vem, em geral, das características do JSC, de algumas otimizações na integração com o sistema (ou redução de funcionalidades) e da escolha de boas bibliotecas de base.
Por isso, em benchmarks de pequena escala o Bun tende a vencer, mas ao mesmo tempo em benchmarks de grande escala ou de longa duração tende a ficar atrás do Node.js.