分かったこと

その後、Rust 版を製品として作った

4 実装とも同じ 14 コマンドを持ったうえでの比較になった。実メモリで node 版の 1/8、確保量では bun 版の 162 分の 1 である。

PEB とは

Process Environment Block。プロセスごとに 1 つ用意される構造体で、そのプロセスの素性を持っている。コマンドライン・環境変数・カレントディレクトリ・読み込んだ DLL の一覧などが入っている。

ここを読むのは、他プロセスのコマンドラインを取る公式の口が無いため。GetCommandLine() という API はあるが、自分自身のものしか返さない。一覧を取る CreateToolhelp32Snapshot も、返すのは pid ・ 親 pid ・ 実行ファイル名までで、引数は持っていない。そこで相手のメモリを直に読みに行くことになる。

3 段目の「長さ ＋ 番地」の並びは UNICODE_STRING と呼ばれる形で、Windows の内部で文字列を渡すときに使われる。終端の記号を持たず、長さで区切る。

waiters が待受けを見分ける手がかりは wait :ID: というコマンドラインそのものなので、4 段目まで辿れないと道具として成り立たない。

これで C# 版への依存が切れた。一時は委譲によって「Windows では C# 版が waiters の本体」という向きになっていたが、API を直に呼べるようになって解消した。

測り方を分けてあるのは、上の 5 実装の表が「起動」を見ているのに対し、こちらは張りっぱなしの状態を見ているため。道具も tools/40_test/benchmark-waiters.mjs に分けた (PowerShell ではなく node で書いてある。Mac ・ Linux でも測れるようにするため)。

5 実装を 1 枚に

読み取れること

常駐のコストは Rust が圧倒的に低い

実メモリ (Working Set)で Rust 4.89 MB ・ Go 8.08 MB ・ C# 24.90 MB ・ bun 25.59 MB ・ node 58.24 MB。確保量 (Private Bytes)ではさらに差が開き、Rust は 0.84 MB しか確保していない。bun の 108.43 MB とは 129 倍になる。

bun は「軽い」とは言い切れない

起動は bun が最速で、Rust より速い

中央値で bun 16.9 ms < Rust 21.1 ms < Go 24.8 ms < node 43.6 ms ≒ C# 44.0 ms。ネイティブの実行ファイルが bun に負けるのは意外だが、この領域ではプロセスを 1 つ作る手間そのものが大きい。詳しくは 起動の速さ に書いた。

機能の量が違うことを忘れない

Rust 版・Go 版は待受けの 1 コマンドしか持たない。製品の 2 本は say ・ who ・ waiters ・ recent ・ restart などを備え、引数の検証・JST の整形・カーソルの保存まで面倒を見ている。行数で 2,985 行 ・ 2,061 行 に対して 111 行 ・ 124 行 である。

置き換えを考えるなら、常駐する wait だけを別の実行ファイルに切り出す形になる。この資料はその判断材料までで、実装の計画はまだ無い。

node で動かすと、往復ごとに 15 ms 乗る

この資料は起動だけを測っていて、API を叩く時間は測っていない。サーバーを測ったときに分かったことを 1 つ書いておく。

つまり node 版の say は、起動 43.6 ms に 15 ms を足した値になる。bun 版なら 16.9 ms のままである。起動の表だけを見て node と bun の差を 27 ms と読むと、実際より小さく見積もることになる。

待受け中のメモリ

いちばん知りたかったところ。待受けを立ち上げて 10 秒待ち、2 秒おきに 5 回測る。それを 3 回繰り返した平均である。子プロセスが居れば合算する (bun は子を作らないため、どの実装も 1 プロセスだった)。

実メモリ (Working Set)

確保量 (Private Bytes)

数値

単位は MB。幅は 3 回 × 5 サンプル、計 15 点の最小と最大。どの実装もぶれが小さく、待受けはずっと同じ量を掴んだまま動く。

実メモリと確保量の違い

ランタイムを持つ 3 実装 (node ・ bun ・ Go)は、使う予定の領域をまとめて確保してから、必要になった分だけ物理メモリに載せる。だから確保量が実メモリを上回る。Rust 版は逆で、確保量 0.84 MB に対して実メモリ 4.89 MB — この差は実行ファイルそのものと、OS が貸している共有ライブラリの分である。

何本張れるか

待受けはプロジェクトにつき 1 本。同時に 5 本張ったときの実メモリを単純に足すと、こうなる。

起動の速さ

--help を渡して、起動して 1 行出して終わるまでを測った。ウォームアップ 3 回のあと 20 回。実装の並び順による差を見るため、順番を変えて 2 巡している。

単位は ms。1 巡目と 2 巡目の差はどれも 1 ms 前後で、順番による偏りは無かった。

読み取れること

アプリのコードはほとんど乗っていない

node 版 43.6 ms に対して、素の node -e 0 が 42.3 ms。差は 1.3 ms しかない。chat.mjs と 3 つのモジュール、計 2,061 行を読んで構文解析する分がこれである。起動時間の 97% は Node そのものの立ち上がりで、アプリを削っても速くならない。

bun も同じで、bun 版 16.9 ms に対して素の bun が 18.1 ms。誤差の中に埋もれている。

C# 版が node と並ぶのは意外だった

ネイティブの実行ファイルなら速いと思っていたが、44.0 ms で node 版と変わらない。.NET は実行ファイル自体が 68.5 KB でも、走らせるには共有のランタイムを読み込んで JIT を立ち上げる必要がある。そこが node の立ち上がりと同じくらいかかっている。

Rust・Go が bun に負ける

ただし待受けでは効かない

待受けは 12 時間に 1 回しか起動しない。起動が 20 ms 速いことには、ほとんど意味が無い。効くのは say ・ who のように何度も叩くコマンドのほうで、そこでは bun が有利になる。

ソースと実行ファイルの大きさ

ソースの行数

C# 版が node 版より 45% 多い。JSON の読み書き (Json.cs 256 行)が標準で用意されておらず、自前で持っているのが効いている。node 側はこれが JSON.parse の 1 行で済む。

実行ファイルの大きさ

Rust 版が 4.63 MB もあるのは、外部クレートを 1 つも使っていないのに標準ライブラリを丸ごと抱き込むためである。Go 版の 8.13 MB も同じで、net/http を入れた分だけ大きい。

ビルドと文法チェックの時間

コードを直してから確かめられるまでの待ち時間である。node 版・bun 版はビルドが無いので 0 msだが、代わりに TypeScript の検査を掛けるとどうなるかを測った。

単位は ms。Go の 1 回目 1,362 ms はビルドキャッシュが空だったため。2 回目以降は標準ライブラリの再コンパイルが要らなくなり、435 〜 518 ms に落ち着く。

Rust は 111 行に対して 457 ms かかっている。キャッシュの効き方は Go と違い、1 回目から 3 回目までほぼ変わらない。単一ファイルを rustc に直接渡しているので、毎回まるごとやり直している。

TypeScript の文法チェック

まだ TypeScript 化していないので、allowJs ＋ checkJs で .mjs のまま型検査に掛けた。設定は tmp/tsc-check/tsconfig.json に置いた一時のもの。

{
	"compilerOptions": {
		"target": "ES2022",
		"module": "ESNext",
		"moduleResolution": "bundler",
		"allowJs": true,
		"checkJs": true,
		"noEmit": true,
		"strict": false,
		"skipLibCheck": true,
		"types": ["node"]
	},
	"include": ["../../src/client/*.mjs"]
}

どちらも実際に落ちる場所ではない(サーバーが返す形は決まっている)。それでも、320 ms で 5 件の「保証できていない箇所」が機械的に出てくるのは、2,061 行を目で読むより確実である。

測り方

環境

使ったもの

測る手順

踏んだ落とし穴

待受けが起動直後に落ちる

初めて繋ぐ相手には案内だけ出して終わる仕様になっている (課題の i260909-01)。そのままだとメモリを測る前に消える。

先に --wait-sec 1 で 1 回走らせてカーソルを立ててから、本番の --wait-sec 600 を立てる。2 回目以降は普通にぶら下がる。

CLI の案内が例外になる

繋ぎ先の案内を標準エラーに出すため、$ErrorActionPreference = 'Stop' のもとでは NativeCommandError になって止まる。

function Invoke-Quiet {
	param([string] $File, [string[]] $Arguments)
	$prev = $ErrorActionPreference
	$ErrorActionPreference = 'Continue'
	try { & $File @Arguments *> $sink } finally { $ErrorActionPreference = $prev }
}

局所的に Continue へ落として、抜けるときに戻す。スクリプト全体を Continue にすると、本物のエラーまで見逃す。

リダイレクト先のファイルが競合する

待受けと起動測定で同じ捨て場を共有していたため、別のプロセスで使用されているで落ちた。毎回 [guid]::NewGuid() で別名にし、プロセスを止めてから 500 ms 待って消す。

Bash から呼ぶと出力が化ける

この測り方の限界

• Rust 版・Go 版は製品と同じ仕事をしていない。引数の検証・JST の整形・カーソルの保存・エラーの案内を持たない。機能を足せばメモリも大きさも増える
• 1 台のマシンでの値である。.NET ランタイムが入っていない環境では C# 版の起動が変わる
• ビルド時間はキャッシュの状態に強く依存する。Go の 1 回目と 3 回目で 3 倍以上ちがった
• tsc の 5 件は、緩い設定での値である。strict を入れれば桁が変わる