#なぜ今日これを選んだか

Rustを学ぶ理由のひとつは「速いものを自分の手で作れるようになる」こと。この記事はTokioの内部に潜る話ではなく、「速さはどこで失われ、どう取り戻すか」を数字つきで示す実務の原則集だった。The Bookを終えた先に何があるかが見える1本。

#要点

• 最適化の前に実測する。 スケジュール遅延などのメトリクスを先に取り、ユーザーに影響しない「見た目の問題」を追わない
• レイテンシはこまめに yield_now で改善する。 Redis型のパイプライン処理で4回読むごとにyieldを挟むと、P50が0.967ms→0.105ms、P99が2.548ms→0.320msになった
• スループットはまとめて処理する。 ファイル操作や spawn_blocking は1回ずつ呼ばずバッチにしてオーバーヘッドを削る
• ロックは短く、I/O中に持たない。 「RwLockが正解になることはほぼない」と言い切っている
• 並行数は Semaphore で上限を切る。 リソース枯渇はランタイムのせいではなく、制限を入れていない設計のせい
• 優先度が違う処理はランタイムごと分ける。 低遅延APIとバックグラウンド処理を別Runtime・別コアに置くと、互いのスケジューリングに割り込まない

#自分にとっての示唆

Rustの学習はまだ基礎（The Book / Rustlings）の段階だが、この記事は「所有権や借用が何のためにあるか」の答えのひとつになる。ロックを短く持つ、I/O中は手放す——これは借用の考え方そのものだ。そして最初の原則が「測れ」であることが一番の学び。速さの前に観測があり、これは筋トレの体重記録や英語のクイズ点と同じ構造をしている。明日からの具体策は2つ。Rust枠30分で tokio::main の最小サンプルを1本動かすこと。そしてFORGEのHUB同期（Python）で「どこに何ms使っているか」を一度計ってみること。測らずに速くしようとしない。

原文を読む →