Bun は実行速度が確かに疾そうで、3倍くらい疾い可能性はあるけど、いま表に出ているベンチマークでは比較に使いづらいところも色々ありそうです。 というか 3倍疾いと C/C++ の速度に匹敵するような…？ HTTP Server はわからない部分も多々ありますが、 Deno の FFI と SQlite は遅いのがわかっているから、ベンチマークをそのまま鵜呑みにはしにくいです。 ただ Deno も Bun という良きライバルが登場したことで成長しようとしています。 たとえば FFI の高速化を検討し始めました。
deno-sqlite が遅い理由は前からわかってて、 API とサンドボックスの制限で WAL が利用できないから。 つまり Bun のベンチマークはサンドボックスなしの利点を考慮しないといけないし、 Deno もサンドボックスの欠点にはもっと議論が必要であるとわかります。 他にも利点欠点が better-sqlite3 のページに結構詳しく書かれています。 確かに高速性を追求するとメモリやディスクの共有は必要になりがちなので、 高速化領域ではこのような話が問題になりやすそうで、Deno の弱点かも知れません。
こちらの議論も活発化してきて、ブラウザの File System Access API を利用したり、 FFI 経由での高速化を目指すなどの話が上がっています (下)。 File System Access API でできるなら一番綺麗そうな気はするけど、Firefox が拒否しているからあまり進まなそうです。 DB や HTTP Server、その他でも高速が必要となると、read/write の多重化はたいてい必要になりそうで、 その結果セキュリティがどうなるかまでは考えてないけど、 言われてみれば確かにサンドボックスの拡張ができると嬉しいかも知れません。
ただ FFI をベースにした async-sqlite3 のベンチマークを見ていると、FFI が一番有望なのかもと感じます。 FFI が速くなればたいていの問題は解決しそうです。
あとこの結果を見ていると、言語として Python より早くても、read/write を経由すると遅くなる側面も見て取れます。 大規模な read/write に弱い、JavaScript (Node/Deno?) 特有の課題を感じますね。 やっぱり FFI の高速化は Node / Deno の責務なんじゃないかなあ。 その意味では Bun の目の付け所は上手いかも。
ここまでの話をまとめると、Bun が疾い話には Deno の制約の話が数多く含まれています。 Bun はそこをセルフ実装のパワーで解決しようとしており、 Node/Deno は互換性やセキュリティを大切に解決しようとしています。 Deno の進化も Bun の進化も、どちらもまだまだの状態なので、どちらも生暖かく応援しようという感じ。 プログラミング言語を作るのって難しいんだなあと、改めて思いました。
個人的には Deno と Node と Bun の関係は、Java と Scala のような関係とは異なると思っています。 基本的な根っこは同じで、また応用部分も ESM で相互運用可能になるはずで、長期的にはどれで書いてもそんなに困らないはずです。 そんな時に大事なのはシンプルさと速度ですから、Deno と Bun には注目です。
追記: 書き終わった後に似たようなことが公式でも書かれていることに気付きました。oh... 何にしても Deno も Bun もこれからですね。
0 件のコメント:
コメントを投稿