【テクニカル・上級編】Dartのnum型が持つ「実行時型判定」のコストと、int/doubleへのキャストが推奨される理由 – Dart コア文法・オブジェクト指向・Null安全解析バイブル

Dartランタイムの深淵：`num`型が隠す多態性のコストと、型特化（Type Specialization）の数理

Dartエコシステムにおいて、`int`と`double`の抽象基底である`num`型は、一見するとポリモーフィックなコードを書くための便利な道具に見える。しかし、ランタイムエンジンの内部構造、とりわけDart VMのJIT/AOTコンパイラおよびメモリ管理の挙動を熟知するエンジニアであれば、コード内の無防備な`num`の多用が、コンパイラ最適化のパイプラインにおいてどれほどの致命傷になり得るかを知っている。

本稿では、`num`型が引き起こす実行時型判定のオーバーヘッド、ボックス化（Boxing）の悪夢、そしてなぜ厳格な型特化がハイパフォーマンスな非同期処理において不可欠であるのかを、ランタイムの底流から解き明かす。

—

1. `num`型とは何か：静的型付けの仮面を被った多態性

Dartは強力なサウンド・タイプシステム（Sound Type System）を持つ言語である。しかし、静的に型が検査されることと、機械語レベルで効率的に実行されることは同義ではない。

`num`型は、`int`と`double`の両方を内包するスーパータイプとして定義されている。コンパイル時、`num`として宣言された変数や引数は、静的解析器（Analyzer）の視点では安全に扱われる。しかし、コンパイラ（Dart VMのAOTコンパイラやJITの最適化パイプライン）の視点に立ったとき、`num`は「実行時までその具体的なサイズと表現形式が決定しない不確定なデータ構造」に変貌する。

// 一見無害に見える num 型の演算
num calculate(num a, num b) {
return a + b;
}

このコード片がDart VMで実行されるとき、何が起きるか。`a`と`b`がそれぞれ`int`なのか、あるいはIEEE 754倍精度浮動小数点数（`double`）なのかを、CPUは実行時に判定しなければならない。

—

2. ランタイムの裏側：型タグ（Type Tagging）とボックス化のコスト

64ビットアーキテクチャにおいて、Dart VM（特に非圧縮ポインタ環境や特定のAOTターゲット）は、メモリ効率と型安全性を両立させるためにタグ付きポインタ（Tagged Pointers）を採用している。

Small Integer (Smi): 64ビットレジスタの下位1ビットを `0` に設定し、残りの63ビットで整数を表現する（実質62ビット＋符号）。これにより、ヒープ割当（Allocation）を行わずにレジスタ上で直接演算ができる。
Heap Object (Double / Large Int): 値がSmiの範囲を超える場合、あるいは`double`型である場合、値はヒープ上にアロケートされ、ポインタの下位ビットにタグ（`1`など）が付与される。これがボックス化（Boxing）である。

ここで`num`型が登場する。`num`型の変数が渡された場合、コンパイラはそれがSmiなのか、ヒープ上の`double`なのかをコンパイル時に確定できない。そのため、以下のようなコストが発生する。

1. インラインキャッシュ（IC: Inline Caches）のミスとメガモーフィック状態:
ポリモーフィックな演算サイトでは、Dart VMは型フィードバック（Type Feedback）を収集する。もし`num a + num b`の演算が、ある時は`int + int`、ある時は`double + int`として侵入されると、ICはメガモーフィック（Megamorphic）状態に陥る。これはディスパッチテーブルのルックアップを引き起こし、CPUパイプラインをストールさせる。
2. 型タグの動的チェック（Type Guarding）:
演算の直前に、レジスタ内の値が整数であるか浮動小数点数であるかを判別するビット演算（Type Tag Check）が必ず挿入される。

—

3. イベントループとマイクロタスクへの波及

Flutterや高スループットなサーバーサイドDart（Shelf等）において、イベントループ（Event Loop）の効率はアプリケーションの生命線である。Isolate内のマイクロタスクキュー（Microtask Queue）やイベントキューが高速に消化されるためには、CPUキャッシュのヒット率と、JIT/AOTによる機械語のインライン展開（Inlining）が不可欠である。

もしホットパス（Hot Path）上に`num`型が氾濫していると、以下のような連鎖的悪影響が生じる。

エスケープ解析（Escape Analysis）の失敗: コンパイラは値がヒープに逃げない（＝スタック上に留まる、あるいはレジスタ内で完結する）ことを証明できなくなり、不要なメモリ割り当てとGC（ガベージコレクション）の圧迫を引き起こす。
JITの逆最適化（Deoptimization）: 実行時に想定外の型が流れ込んだ瞬間、JITコンパイラは最適化された機械語を破棄し、インタプリタや低速なランタイムStubへフォールバック（Deopt）する。このコストは極めて重い。

—

4. 実証：`num` vs 厳密な型特化（`int` / `double`）のベンチマーク的思考

以下のコードを考えてほしい。ミリ秒単位の処理速度が要求されるデータ処理パイプラインや暗号処理、あるいはゲームの物理演算ループを想定する。

// 【アンチパターン】num 型による多態性の強制
num processMetricsNum(num rawValue) {
// 実行時型判定が毎ループ発生する
return rawValue 1.05 + 10;
}

// 【推奨アプローチ】明示的な型キャストと特化
double processMetricsStrict(double rawValue) {
// コンパイル時に型が確定しており、CPUのFPU命令へ直接マッピングされる
return rawValue 1.05 + 10;
}

int processMetricsInt(int rawValue) {
// Smi演算としてレジスタ上で完結する可能性が高い
return (rawValue 105 ~/ 100) + 10;
}

コンパイラ視点での評価

`processMetricsNum`: 引数が`int`で渡された場合でも、戻り値が`num`であるため、コンパイラは結果をどの表現形式で返すべきか実行時判断を強いられる。結果として、整数演算であっても浮動小数点演算器（FPU）への切り替えやボックス化のコストを支払う羽目になる。
`processMetricsStrict` / `processMetricsInt`: 型が完全に静的に固定されているため、DartのAOTコンパイラ（AppJIT / AOT）は、この関数を呼び出し元に完全インライン展開（Inlining）し、冗長な型チェックコードを完全に排除（Dead Code Elimination）することができる。

—

5. シニアエンジニアのための防衛的コーディング規約

コードベース全体の型安全性を高め、ランタイムの予測可能性を最大化するために、以下の原則をチームに強制すべきである。

1. API境界以外での `num` の使用禁止:
外部JSONのパースや、型が完全に不定な動的データを扱うレガシーな境界（`dynamic`からの変換地点）を除き、内部ロジックの関数シグネチャに `num` を採用してはならない。
2. 明示的な型変換（Cast & Coercion）の徹底:
もしAPIから返却された値が `num` であることが分かっている場合は、処理の最上流で速やかに `.toInt()` または `.toDouble()` を呼び出し、具象型へダウンキャストする。
3. Linterの活用:
`analysis_options.yaml` において、暗黙的なキャストや曖昧な型推論を厳しく制限するルールを適用する。

analyzer:
language:
strict-casts: true
strict-inference: true
strict-raw-types: true

—

結言

Dartは、その美しい構文の裏に、徹底したパフォーマンスチューニングの哲学を隠し持っている。`num`型は言語仕様上の利便性を提供する一方で、ランタイムの最適化エンジンにとっては「不確定要素」という名のノイズでしかない。

シニアエンジニアたる者、記述されたコードがDart VM上でどのようにバイトコードにコンパイルされ、どのレジスタにロードされ、いかにしてCPUパイプラインを駆け抜けるか――その一連のライフサイクルを常に脳内でトレースし続けなければならない。型を制する者が、ランタイムを制す。