SWC製のExecutorをリリースした

特徴と仕組み

コード、依存関係を全てプロセス単位で繋げvmインスタンスで実行しています。
実行環境のvmではStability:2 Stable(安定的機能)のvm.Scriptを採用しました。
TypeScript形式の変換にはタイトル通りswcの@swc/coreを採用しています。

node --importではESMが強制され、 node --requireではrequire、CJSが強制されます。
このコンテキストを回避するために全てのコードをcommonjsに変換しトランスパイルしています。

全てCJSに変換するためCJSとESMが混在する環境で安定的に動きます。
実はこれは0.0.x段階でのtype: moduleを付けたESMしかサポートしないコンセプトとはかけ離れていますが、vm.Scriptで実行するためどちらも可能となりました。

この0.x.0のコンセプトはNext.jsをcommonjsとして起動しコードを実行するnext dev --turbopackから影響を受けました。

インストール

pnpm i -D rscute@latest

npxで実行

npx rscute file.ts

プログラム

const { JIT } = require('rscute');

await JIT(absolutePath)

await import()をawait JIT()に置き換える
JITはrscuteのmainに登録されてるメイン関数でありCLI rscute自身がJIT関数で動いているためセルフ実行していることになります。

await import()や require()をforでループしてファイルを実行する際に起きていた圧倒的ボトルネックをVM(V8) JIT Compilerのインスタンス上で実行することで解決出来たと思います。

実現できたこと

最初の課題がインメモリ上での実行でした。
0.0.x段階でオンデマンドにディスク上にトランスパイルしたコピーtempを生成し実行、プロセス終了時に削除していました。これはファイルが多すぎる場合ディスク負荷も心配ですが、実行速度がディスクから実行されるため顕著に遅かったです。

そこで考えたのが依存解決のパス解決をそもそもしないでコード単位で集めたデータを実行するアプローチでした。 ここで発生するボトルネックはプロセス単位で作られる1インスタンスを作るためのコストに集約されます。

npxでbinを検索すること自体に約80ms(0.08秒)がかかるためできるだけ実ファイルもしくはbinを直接起動してあげると速さに困ることはなさそうです。

速さのベンチマークですが、比較対象が多すぎるのととりあえず使ってみないとわからないところもあると思うため敢えてここでは載せません。

最後に特徴ですが、register系は単発ファイルにおいてnodeと同一程度並のパフォーマンスを出しますが、依存関係が多い場合にNode.jsのローダーに丸投げしているため重たくなっていきます、今回の様に変換にswcを使い依存関係の処理を自前でやることでモジュールローダーに頼らない高速な処理が実現出来たみたいです。