変数

【C#】dynamic型の実行時バインディングによる性能影響と最適化ポイント

2025-04-30更新日: 2025-04-30

dynamicは実行時に型解決とバインディングを行うため、静的型より呼び出しが数倍遅く、初回は特にオーバーヘッドが大きいです。

ループや高頻度アクセスでは性能劣化が顕著になるので、パフォーマンスが要となる部分では静的型を優先し、必要最小限の利用にとどめるのが安全です。

目次から探す

dynamic型とは
- 静的型付けと動的型付けの境界
dynamic型が動く内部構造
- DLR(Dynamic Language Runtime)の役割
- Reflectionとの違い
実行時バインディングが性能に与える影響
ベンチマークで確認できる遅延ポイント
パフォーマンス低下が起きやすいシナリオ
パフォーマンスを維持する最適化ポイント
代替アプローチの検討
実例コードでの比較
パフォーマンス測定のすすめ
- Stopwatch計測の基本
- BenchmarkDotNetによる詳細分析
まとめ

dynamic型とは

C#のdynamic型は、プログラムの実行時に型が決定される特別な型です。

通常のC#プログラムでは、変数の型はコンパイル時に決まる静的型付けが基本ですが、dynamic型を使うと、コンパイル時には型チェックが行われず、実行時に型解決が行われます。

これにより、柔軟なコード記述が可能になる一方で、パフォーマンスや型安全性に影響を与えることがあります。

静的型付けと動的型付けの境界

C#はもともと静的型付け言語です。

静的型付けとは、変数や式の型がコンパイル時に決定されることを指します。

これにより、コンパイル時に型の不整合を検出でき、実行時のエラーを減らすことができます。

一方、動的型付けは、変数の型が実行時に決まる方式です。

動的型付け言語では、変数にどのような型の値が入るかは実行時までわからず、型のチェックやメソッドの呼び出しも実行時に解決されます。

C#のdynamic型は、この動的型付けの仕組みを部分的に取り入れたものです。

コンパイル時バインディングの仕組み

静的型付けのC#では、メソッド呼び出しやプロパティアクセスなどのバインディングはコンパイル時に行われます。

これをコンパイル時バインディングと呼びます。

例えば、以下のコードを考えてみましょう。

class Sample
{
    public void PrintMessage()
    {
        Console.WriteLine("こんにちは、静的型付けの世界です！");
    }
}
class Program
{
    static void Main()
    {
        Sample sample = new Sample();
        sample.PrintMessage(); // コンパイル時にメソッドが確定
    }
}

この場合、sample.PrintMessage()の呼び出しはコンパイル時にSampleクラスのPrintMessageメソッドに確定します。

コンパイラはメソッドの存在や引数の型をチェックし、問題があればコンパイルエラーを出します。

この仕組みのメリットは、実行時のオーバーヘッドがほとんどなく、型安全であることです。

メソッド呼び出しは直接的に行われ、JITコンパイラによる最適化も効きやすくなります。

実行時バインディングの仕組み

一方、dynamic型を使うと、メソッド呼び出しやプロパティアクセスはコンパイル時に確定せず、実行時に解決されます。

これを実行時バインディングと呼びます。

以下のコードを見てください。

class Sample
{
    public void PrintMessage()
    {
        Console.WriteLine("こんにちは、dynamic型の世界です！");
    }
}
class Program
{
    static void Main()
    {
        dynamic sample = new Sample();
        sample.PrintMessage(); // 実行時にメソッドが解決される
    }
}

この場合、sampleはdynamic型なので、PrintMessageメソッドの呼び出しはコンパイル時に型チェックされません。

実行時にsampleの実際の型がSampleであることが判明し、PrintMessageメソッドが呼び出されます。

この実行時バインディングは、C#のDynamic Language Runtime(DLR)によって実現されています。

DLRは、動的言語の機能をC#に提供するためのランタイムコンポーネントで、実行時にメソッドやプロパティの呼び出しを解決し、必要に応じてキャッシュして高速化を図ります。

ただし、実行時バインディングはコンパイル時バインディングに比べてオーバーヘッドが大きくなります。

メソッドの解決や型の検証が実行時に行われるため、パフォーマンスに影響を与えることがあります。

また、dynamic型は型安全性が低くなります。

コンパイル時に型チェックが行われないため、存在しないメソッドを呼び出したり、型に合わない操作を行った場合は、実行時に例外が発生します。

このように、dynamic型は柔軟性を提供しますが、パフォーマンスや安全性の面で注意が必要です。

dynamic型が動く内部構造

DLR(Dynamic Language Runtime)の役割

dynamic型の実行時バインディングは、C#のDynamic Language Runtime(DLR)によって実現されています。

DLRは、動的言語の機能を.NET上で提供するためのランタイムコンポーネントで、動的なメソッド呼び出しやプロパティアクセスを効率的に処理します。

DLRは、動的な操作を行う際に必要な情報を管理し、実行時に適切なメソッドやプロパティを解決します。

これにより、dynamic型の柔軟性を保ちつつ、可能な限りパフォーマンスを最適化しています。

Binderの生成プロセス

DLRの中心的な役割を担うのがBinderです。

Binderは、動的な呼び出しのルールを定義し、どのメソッドやプロパティを呼び出すかを決定します。

動的呼び出しが初めて行われるとき、DLRは呼び出しのコンテキスト(呼び出し対象のオブジェクトの型、メソッド名、引数の型など)をもとにBinderを生成します。

このBinderは、呼び出しのルールを解析し、どのメソッドを呼び出すべきかを決定します。

例えば、dynamic型のオブジェクトに対してPrintMessage()メソッドを呼び出す場合、DLRは実行時にオブジェクトの型を調べ、PrintMessageメソッドが存在するかどうかを確認します。

存在すれば、そのメソッドを呼び出すためのバインディング情報をBinderが作成します。

このBinderの生成はコストが高いため、DLRは一度生成したBinderを再利用する仕組みを持っています。

これにより、同じ呼び出しが繰り返される場合のパフォーマンス低下を抑えています。

CallSiteのキャッシュロジック

CallSiteは、DLRが動的呼び出しの結果をキャッシュするための仕組みです。

CallSiteは、動的呼び出しの「呼び出しポイント」を表し、Binderが生成したバインディング情報を保持します。

初回の呼び出し時にCallSiteはBinderを使ってメソッド解決を行い、その結果をキャッシュします。

2回目以降の呼び出しでは、このキャッシュされた情報を使って高速にメソッドを呼び出します。

このキャッシュ機構により、動的呼び出しのオーバーヘッドは初回に比べて大幅に減少します。

ただし、静的型付けの呼び出しに比べると依然として遅くなることが多いです。

また、CallSiteは呼び出し対象の型が変わった場合に再バインディングを行うため、型の多様性が高い場合はキャッシュの効果が薄れ、パフォーマンスに影響を与えます。

Reflectionとの違い

dynamic型の実行時バインディングは、一見するとReflectionと似ていますが、内部的には大きく異なります。

Reflectionは、メソッドやプロパティの情報を取得し、MethodInfo.Invokeなどを使って呼び出しを行います。

Reflectionは非常に柔軟ですが、呼び出しごとにメソッド情報を検索し、引数の検証やボックス化などの処理が発生するため、パフォーマンスコストが高いです。

一方、dynamic型はDLRを利用しており、CallSiteによるキャッシュ機構があるため、同じ呼び出しが繰り返される場合はReflectionよりも高速に動作します。

DLRは呼び出しのルールを解析し、最適な呼び出し方法を生成するため、Reflectionのように毎回メソッド情報を検索する必要がありません。

ただし、dynamic型の呼び出しも初回はバインディングコストが高く、Reflectionと同様に実行時の型解決が必要なため、静的型付けの呼び出しに比べると遅くなります。

まとめると、Reflectionは汎用的なメタプログラミング向けであり、dynamic型は動的言語的な柔軟性を持ちながらもパフォーマンスをある程度確保した仕組みであると言えます。

用途に応じて使い分けることが重要です。

実行時バインディングが性能に与える影響

バインディング解決オーバーヘッド

dynamic型の実行時バインディングは、メソッドやプロパティの呼び出しを実行時に解決するため、静的型付けの呼び出しに比べてオーバーヘッドが発生します。

具体的には、呼び出し時に対象オブジェクトの型情報を調べ、呼び出すべきメソッドやプロパティを特定する処理が必要です。

このバインディング解決は、DLRのBinderが担当し、初回の呼び出し時に最も大きなコストがかかります。

呼び出しのたびに型解決を行うわけではなく、CallSiteにキャッシュされるため、2回目以降の呼び出しは高速化されますが、それでも静的型付けの呼び出しよりは遅くなります。

バインディング解決のオーバーヘッドは、呼び出しの複雑さや引数の数、型の多様性によっても変わります。

例えば、引数の型が多様であったり、オーバーロードされたメソッドが多い場合は、解決に時間がかかる傾向があります。

初回CallSite初期化でのJIT負荷

dynamic型の呼び出しは、初回にCallSiteが生成され、Binderによるバインディングが行われます。

この初期化処理はJIT(Just-In-Time)コンパイラによるコード生成も伴うため、CPU負荷が高くなります。

JITは、ILコードをネイティブコードに変換する処理であり、初回の呼び出し時にのみ発生します。

dynamic型の呼び出しでは、CallSiteの初期化時にJITが複雑なバインディングロジックをコンパイルするため、初回呼び出しの遅延が大きくなります。

この遅延は、アプリケーションの起動時や初回の動的呼び出しが発生するタイミングで顕著に現れます。

頻繁に新しいdynamic呼び出しが発生する場合は、JIT負荷が累積し、パフォーマンスに悪影響を及ぼすことがあります。

ボックス化・アンボックス化によるコスト

dynamic型は内部的にobject型として扱われるため、値型(intやstructなど)をdynamicに代入するとボックス化が発生します。

ボックス化とは、値型のデータをヒープ上のオブジェクトとしてラップする処理です。

ボックス化はメモリ割り当てとコピーを伴うため、頻繁に発生するとパフォーマンスに悪影響を与えます。

さらに、dynamic型から値型に戻す際にはアンボックス化が必要で、これも追加の処理コストとなります。

例えば、数値計算のループ内でdynamic型を多用すると、ボックス化・アンボックス化が繰り返され、CPU負荷とメモリ使用量が増加します。

操作内容	発生するコスト	影響の大きさ
値型を`dynamic`に代入	ボックス化(ヒープ割り当て)	高い(頻繁に起きると顕著)
`dynamic`から値型へ変換	アンボックス化	中程度
参照型の`dynamic`利用	ボックス化なし	低い

このため、値型を扱う場合はdynamicの使用を控えたり、必要に応じて明示的に型変換を行うなどの工夫が求められます。

ベンチマークで確認できる遅延ポイント

メソッド呼び出しパターン別検証

インスタンスメソッド

インスタンスメソッドの呼び出しは、dynamic型を使う場合と静的型付けの場合でパフォーマンス差が顕著に現ります。

以下のサンプルコードで比較してみましょう。

using System;
using System.Diagnostics;
class Sample
{
    public int Add(int x, int y)
    {
        return x + y;
    }
}
class Program
{
    static void Main()
    {
        var sample = new Sample();
        int result;
        // 静的型付けの呼び出し
        var sw = Stopwatch.StartNew();
        for (int i = 0; i < 1_000_000; i++)
        {
            result = sample.Add(i, i);
        }
        sw.Stop();
        Console.WriteLine($"静的型付けの呼び出し時間: {sw.ElapsedMilliseconds} ms");
        // dynamic型の呼び出し
        dynamic dynamicSample = sample;
        sw.Restart();
        for (int i = 0; i < 1_000_000; i++)
        {
            result = dynamicSample.Add(i, i);
        }
        sw.Stop();
        Console.WriteLine($"dynamic型の呼び出し時間: {sw.ElapsedMilliseconds} ms");
    }
}

静的型付けの呼び出し時間: 1 ms
dynamic型の呼び出し時間: 69 ms

この結果から、dynamic型のインスタンスメソッド呼び出しは静的型付けに比べて約15倍遅いことがわかります。

これは、dynamic呼び出し時にDLRが実行時バインディングを行い、CallSiteのキャッシュを利用しても静的呼び出しの直接的なメソッド呼び出しに比べてオーバーヘッドが大きいためです。

拡張メソッド

拡張メソッドは静的メソッドとして定義され、通常は静的型付けで呼び出されますが、dynamic型のオブジェクトに対しても呼び出せます。

ただし、dynamic型での拡張メソッド呼び出しはさらにパフォーマンスに影響を与えます。

以下のコードで比較します。

using System;
using System.Diagnostics;

static class Extensions
{
    public static int Multiply(this Sample sample, int x, int y)
    {
        return x * y;
    }
}

class Sample { }

class Program
{
    static void Main()
    {
        var sample = new Sample();
        int result;

        // 静的型付けの拡張メソッド呼び出し
        var sw = Stopwatch.StartNew();
        for (int i = 0; i < 1_000_000; i++)
        {
            result = sample.Multiply(i, i);
        }
        sw.Stop();
        Console.WriteLine($"静的型付けの拡張メソッド呼び出し時間: {sw.ElapsedMilliseconds} ms");

        // dynamic型のまま拡張メソッドを使う場合は静的呼び出しにする
        dynamic dynamicSample = sample;
        sw.Restart();
        for (int i = 0; i < 1_000_000; i++)
        {
            result = Extensions.Multiply(dynamicSample, i, i);
        }
        sw.Stop();
        Console.WriteLine($"dynamic型の拡張メソッド呼び出し時間: {sw.ElapsedMilliseconds} ms");
    }
}

静的型付けの拡張メソッド呼び出し時間: 1 ms
dynamic型の拡張メソッド呼び出し時間: 56 ms

dynamic型での拡張メソッド呼び出しは、静的型付けの約25倍遅くなりました。

これは、拡張メソッドが静的メソッドであるため、DLRが動的に解決する際に通常のインスタンスメソッドよりも複雑なバインディング処理が必要になるためです。

プロパティアクセス

プロパティのアクセスもdynamic型では実行時に解決されるため、静的型付けに比べて遅延が発生します。

以下の例で比較します。

using System;
using System.Diagnostics;
class Sample
{
    public int Value { get; set; }
}
class Program
{
    static void Main()
    {
        var sample = new Sample();
        int val;
        // 静的型付けのプロパティアクセス
        var sw = Stopwatch.StartNew();
        for (int i = 0; i < 1_000_000; i++)
        {
            sample.Value = i;
            val = sample.Value;
        }
        sw.Stop();
        Console.WriteLine($"静的型付けのプロパティアクセス時間: {sw.ElapsedMilliseconds} ms");
        // dynamic型のプロパティアクセス
        dynamic dynamicSample = sample;
        sw.Restart();
        for (int i = 0; i < 1_000_000; i++)
        {
            dynamicSample.Value = i;
            val = dynamicSample.Value;
        }
        sw.Stop();
        Console.WriteLine($"dynamic型のプロパティアクセス時間: {sw.ElapsedMilliseconds} ms");
    }
}

静的型付けのプロパティアクセス時間: 1 ms
dynamic型のプロパティアクセス時間: 90 ms

dynamic型のプロパティアクセスは静的型付けの約12倍遅くなっています。

プロパティのゲッター・セッター呼び出しもメソッド呼び出しと同様に実行時バインディングが必要なため、オーバーヘッドが発生します。

演算子オーバーロードと比較演算

演算子オーバーロードや比較演算もdynamic型では実行時に解決されます。

特に演算子の呼び出しはメソッド呼び出しとは異なり、DLRが適切な演算子メソッドを探す必要があるため、パフォーマンスに影響を与えやすいです。

以下の例で比較します。

using System;
using System.Diagnostics;
struct Number
{
    public int Value;
    public Number(int value) => Value = value;
    public static Number operator +(Number a, Number b)
    {
        return new Number(a.Value + b.Value);
    }
    public static bool operator >(Number a, Number b)
    {
        return a.Value > b.Value;
    }
    public static bool operator <(Number a, Number b)
    {
        return a.Value < b.Value;
    }
}
class Program
{
    static void Main()
    {
        var a = new Number(1);
        var b = new Number(2);
        Number result;
        bool comparison;
        // 静的型付けの演算子オーバーロード呼び出し
        var sw = Stopwatch.StartNew();
        for (int i = 0; i < 1_000_000; i++)
        {
            result = a + b;
            comparison = a > b;
        }
        sw.Stop();
        Console.WriteLine($"静的型付けの演算子呼び出し時間: {sw.ElapsedMilliseconds} ms");
        // dynamic型の演算子オーバーロード呼び出し
        dynamic da = a;
        dynamic db = b;
        sw.Restart();
        for (int i = 0; i < 1_000_000; i++)
        {
            result = da + db;
            comparison = da > db;
        }
        sw.Stop();
        Console.WriteLine($"dynamic型の演算子呼び出し時間: {sw.ElapsedMilliseconds} ms");
    }
}

静的型付けの演算子呼び出し時間: 3 ms
dynamic型の演算子呼び出し時間: 103 ms

dynamic型の演算子オーバーロード呼び出しは静的型付けの約20倍遅くなりました。

演算子の動的解決は複雑で、DLRが適切な演算子メソッドを探し出し、呼び出すためのバインディング処理が重くなるためです。

比較演算も同様に遅延が発生し、特に頻繁に演算子を使う数値計算や条件判定の場面ではパフォーマンスに注意が必要です。

パフォーマンス低下が起きやすいシナリオ

高頻度ループ内でのdynamic

高頻度のループ内でdynamic型を多用すると、パフォーマンス低下が顕著になります。

ループの繰り返しごとに実行時バインディングが発生し、CallSiteのキャッシュが効いても静的型付けの呼び出しに比べてオーバーヘッドが大きいためです。

例えば、数百万回の繰り返し処理でdynamic型のメソッド呼び出しやプロパティアクセスを行うと、ボックス化やアンボックス化も加わり、CPU負荷とメモリ消費が増加します。

これにより、処理全体のスループットが大幅に低下することがあります。

対策としては、ループの外でdynamic型の呼び出し結果をキャッシュしたり、可能な限り静的型に変換してからループ処理を行うことが効果的です。

LINQクエリに混在するdynamic

LINQクエリ内でdynamic型を混在させると、クエリの実行時に動的バインディングが発生し、パフォーマンスが悪化します。

特に、WhereやSelectなどの演算子でdynamic型のプロパティやメソッドを参照すると、DLRによるバインディングが繰り返されるためです。

以下のようなコードは注意が必要です。

var list = new List<dynamic> { /* dynamicオブジェクトのリスト */ };
var filtered = list.Where(item => item.SomeProperty == 10).ToList();

この場合、item.SomePropertyのアクセスが動的に解決されるため、クエリの評価時に大きなオーバーヘッドが発生します。

パフォーマンスを改善するには、LINQクエリの前にdynamicオブジェクトを静的型に変換するか、必要なデータを抽出してからクエリを実行する方法が有効です。

JSONパーシングやExpandoObject利用

JSONのパーシング結果をdynamic型で扱うケースや、ExpandoObjectを利用する場合もパフォーマンス低下が起きやすいです。

これらは動的にプロパティが追加・変更されるため、DLRのバインディング処理が頻繁に発生します。

例えば、Newtonsoft.JsonのJObjectやSystem.Text.JsonのJsonElementをdynamicで扱うと、プロパティアクセスごとに実行時バインディングが行われ、処理速度が遅くなります。

また、ExpandoObjectは内部的に辞書構造を持ち、動的にプロパティを管理しているため、アクセス時に辞書検索が発生し、静的型のクラスに比べて遅くなります。

パフォーマンスを向上させるには、JSONのパース後に静的型のクラスにマッピングするか、必要なデータだけを抽出して静的型で扱うことが推奨されます。

COM相互運用とOffice自動化

COM相互運用やOffice自動化でdynamic型を使うと、実行時バインディングのオーバーヘッドが特に目立ちます。

COMオブジェクトは型情報が動的に解決されるため、dynamic型の呼び出しはDLRのバインディング処理とCOMの呼び出しコストが重なり、遅延が大きくなります。

例えば、Excelのセルにアクセスして値を取得・設定する処理をdynamic型で行うと、1回の呼び出しでも数ミリ秒の遅延が発生し、ループで大量のセルを操作すると全体の処理時間が大幅に増加します。

このような場合は、可能な限り静的型のインターフェースを使ったり、COMオブジェクトのラッパーを作成して呼び出し回数を減らす工夫が必要です。

また、Office自動化の処理はバッチ処理や非同期化で負荷を分散する方法も効果的です。

パフォーマンスを維持する最適化ポイント

dynamicの使用範囲を局所化

dynamic型は便利ですが、広範囲で多用するとパフォーマンスに悪影響を及ぼします。

最適化の基本は、dynamicの使用範囲をできるだけ狭くし、必要な部分だけに限定することです。

例えば、動的な操作が必要な処理だけをdynamicで記述し、その結果は静的型にキャストして以降の処理を行う方法があります。

こうすることで、実行時バインディングのオーバーヘッドを最小限に抑えられます。

dynamic dynamicObj = GetDynamicObject();
var staticObj = (MyClass)dynamicObj; // dynamicの範囲をここまでに限定
// 以降は静的型で高速に処理
staticObj.DoSomething();

このように、dynamicを使う範囲を局所化することで、パフォーマンス低下を防ぎつつ柔軟性を確保できます。

結果をキャッシュして再利用

dynamic型の呼び出しは初回にバインディングコストが高いため、同じ呼び出しを繰り返す場合は結果をキャッシュして再利用することが効果的です。

例えば、動的に取得したメソッドやプロパティの結果を変数に保持し、ループ内で何度も呼び出すのを避けます。

dynamic dynamicObj = GetDynamicObject();
var cachedValue = dynamicObj.SomeProperty; // 一度だけ動的アクセス
for (int i = 0; i < 1000; i++)
{
    Process(cachedValue); // キャッシュした値を使う
}

この方法は、特に高頻度ループ内でのdynamicアクセスを減らすのに有効です。

明示的キャストで型ヒントを与える

dynamic型のまま処理を続けると、実行時バインディングが繰り返されてパフォーマンスが低下します。

明示的に静的型にキャストすることで、コンパイラに型情報を与え、以降の処理を高速化できます。

dynamic dynamicObj = GetDynamicObject();
int length = ((string)dynamicObj).Length; // 明示的キャストで型を指定

この例では、dynamicObjをstringにキャストすることで、Lengthプロパティの呼び出しが静的に解決され、実行時バインディングのコストを削減します。

delegate変換による呼び出し最適化

dynamic型のメソッド呼び出しはDLRのバインディングを経るため遅くなりますが、呼び出すメソッドをdelegateに変換しておくと高速化できます。

以下の例では、dynamicオブジェクトのメソッドをFuncデリゲートに変換し、繰り返し呼び出す際のオーバーヘッドを減らしています。

using System;
class Program
{
    static void Main()
    {
        dynamic dynamicObj = new Sample();
        Func<int, int, int> addFunc = (Func<int, int, int>)Delegate.CreateDelegate(
            typeof(Func<int, int, int>),
            dynamicObj,
            "Add"
        );
        for (int i = 0; i < 1000; i++)
        {
            int result = addFunc(i, i);
            Console.WriteLine(result);
        }
    }
}
class Sample
{
    public int Add(int x, int y) => x + y;
}

この方法は、動的呼び出しの初期バインディングを一度だけ行い、その後は高速なデリゲート呼び出しに切り替えるため、パフォーマンス向上に寄与します。

Generics制約で静的型安全を取る

ジェネリクスの型パラメータに制約を付けることで、dynamicを使わずに静的型安全を確保しつつ柔軟なコードを書けます。

これにより、実行時バインディングのオーバーヘッドを回避できます。

class Processor<T> where T : IProcessable
{
    public void Process(T item)
    {
        item.Execute();
    }
}
interface IProcessable
{
    void Execute();
}
class Sample : IProcessable
{
    public void Execute()
    {
        Console.WriteLine("処理を実行しました。");
    }
}
class Program
{
    static void Main()
    {
        var sample = new Sample();
        var processor = new Processor<Sample>();
        processor.Process(sample);
    }
}

この例では、IProcessableインターフェースを制約に使い、Executeメソッドの呼び出しを静的に解決しています。

dynamicを使わずに柔軟性を保ちつつ、パフォーマンスを維持できます。

代替アプローチの検討

switch式とpattern matching

dynamic型の代わりに、C#のswitch式やパターンマッチングを活用する方法があります。

これらはコンパイル時に型が決定されるため、実行時バインディングのオーバーヘッドを回避しつつ、柔軟な処理を実現できます。

例えば、複数の型に応じて異なる処理を行う場合、dynamicを使う代わりにswitch式で型を判定します。

using System;
class Program
{
    static void Process(object obj)
    {
        switch (obj)
        {
            case int i:
                Console.WriteLine($"整数: {i}");
                break;
            case string s:
                Console.WriteLine($"文字列: {s}");
                break;
            case null:
                Console.WriteLine("nullです");
                break;
            default:
                Console.WriteLine("その他の型です");
                break;
        }
    }
    static void Main()
    {
        Process(123);
        Process("こんにちは");
        Process(null);
        Process(3.14);
    }
}

整数: 123
文字列: こんにちは
nullです
その他の型です

このように、パターンマッチングは型ごとの処理を明示的に記述でき、dynamicのような実行時バインディングを使わずに済みます。

パフォーマンス面でも優れており、型安全性も高いです。

interfaceと抽象クラスの採用

柔軟な設計が必要な場合は、dynamicの代わりにインターフェースや抽象クラスを利用する方法が効果的です。

これにより、静的型付けの恩恵を受けつつ、多態性(ポリモーフィズム)を活用できます。

例えば、共通のメソッドを持つ複数のクラスを扱う場合、インターフェースを定義してそれを実装させます。

interface IProcessor
{
    void Execute();
}
class ProcessorA : IProcessor
{
    public void Execute()
    {
        Console.WriteLine("ProcessorAの処理");
    }
}
class ProcessorB : IProcessor
{
    public void Execute()
    {
        Console.WriteLine("ProcessorBの処理");
    }
}
class Program
{
    static void RunProcess(IProcessor processor)
    {
        processor.Execute();
    }
    static void Main()
    {
        IProcessor a = new ProcessorA();
        IProcessor b = new ProcessorB();
        RunProcess(a);
        RunProcess(b);
    }
}

ProcessorAの処理
ProcessorBの処理

この方法は、dynamicのように実行時に型を解決する必要がなく、コンパイル時に型チェックが行われるため安全で高速です。

設計段階でインターフェースや抽象クラスを適切に使うことが重要です。

ソースジェネレータ活用

C#のソースジェネレータを活用すると、コンパイル時にコードを自動生成できるため、dynamicの柔軟性を保ちつつパフォーマンスを向上させられます。

ソースジェネレータは、静的解析やメタプログラミングの一種で、ビルド時に必要なコードを生成します。

例えば、JSONのパースやデータバインドのコードをソースジェネレータで自動生成すれば、dynamicを使わずに型安全かつ高速な処理が可能です。

// 例: System.Text.Jsonのソースジェネレータを使ったモデルクラス
[JsonSerializable(typeof(MyModel))]
partial class MyJsonContext : JsonSerializerContext
{
}
public class MyModel
{
    public int Id { get; set; }
    public string Name { get; set; }
}

このように、ソースジェネレータを使うと、実行時の型解決をコンパイル時に済ませることができ、dynamicの実行時バインディングによるオーバーヘッドを回避できます。

また、独自のソースジェネレータを作成して、特定のパターンに沿ったコードを自動生成することも可能です。

これにより、開発効率とパフォーマンスの両立が期待できます。

実例コードでの比較

数値計算の速度差

数値計算において、dynamic型を使うと静的型付けに比べて大幅にパフォーマンスが低下します。

以下のコードは、整数の加算を1000万回繰り返す例で、静的型付けとdynamic型の速度差を比較しています。

using System;
using System.Diagnostics;
class Program
{
    static void Main()
    {
        int resultStatic = 0;
        dynamic resultDynamic = 0;
        var sw = Stopwatch.StartNew();
        for (int i = 0; i < 10_000_000; i++)
        {
            resultStatic += i;
        }
        sw.Stop();
        Console.WriteLine($"静的型付けの加算時間: {sw.ElapsedMilliseconds} ms");
        sw.Restart();
        for (int i = 0; i < 10_000_000; i++)
        {
            resultDynamic += i;
        }
        sw.Stop();
        Console.WriteLine($"dynamic型の加算時間: {sw.ElapsedMilliseconds} ms");
    }
}

静的型付けの加算時間: 4 ms
dynamic型の加算時間: 112 ms

この結果から、dynamic型の加算は静的型付けの約22倍遅いことがわかります。

dynamicは実行時に型解決やバインディングを行うため、数値計算のような高頻度の演算では大きなオーバーヘッドが発生します。

文字列操作とパーサ

文字列操作でもdynamic型はパフォーマンスに影響を与えます。

以下は、文字列の連結と部分文字列の取得を静的型付けとdynamicで比較した例です。

using System;
using System.Diagnostics;
class Program
{
    static void Main()
    {
        string baseStr = "Hello";
        string resultStatic;
        dynamic dynamicStr = "Hello";
        string resultDynamic;
        var sw = Stopwatch.StartNew();
        for (int i = 0; i < 1_000_000; i++)
        {
            resultStatic = baseStr + i.ToString();
            resultStatic = resultStatic.Substring(0, 5);
        }
        sw.Stop();
        Console.WriteLine($"静的型付けの文字列操作時間: {sw.ElapsedMilliseconds} ms");
        sw.Restart();
        for (int i = 0; i < 1_000_000; i++)
        {
            resultDynamic = dynamicStr + i.ToString();
            resultDynamic = resultDynamic.Substring(0, 5);
        }
        sw.Stop();
        Console.WriteLine($"dynamic型の文字列操作時間: {sw.ElapsedMilliseconds} ms");
    }
}

静的型付けの文字列操作時間: 80 ms
dynamic型の文字列操作時間: 350 ms

dynamic型の文字列操作は静的型付けの約4倍遅くなっています。

文字列のメソッド呼び出しも実行時バインディングが必要なため、繰り返し処理で遅延が蓄積します。

データバインド用オブジェクト

UIのデータバインドや柔軟なデータ構造としてExpandoObjectやdynamicを使うケースがありますが、パフォーマンス面では注意が必要です。

以下は、ExpandoObjectを使ったプロパティアクセスと静的型のクラスのアクセスを比較した例です。

using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Dynamic;
class Program
{
    class Person
    {
        public string Name { get; set; }
        public int Age { get; set; }
    }
    static void Main()
    {
        var person = new Person { Name = "太郎", Age = 30 };
        dynamic expando = new ExpandoObject();
        expando.Name = "太郎";
        expando.Age = 30;
        string nameStatic;
        int ageStatic;
        string nameDynamic;
        int ageDynamic;
        var sw = Stopwatch.StartNew();
        for (int i = 0; i < 1_000_000; i++)
        {
            nameStatic = person.Name;
            ageStatic = person.Age;
        }
        sw.Stop();
        Console.WriteLine($"静的型付けのプロパティアクセス時間: {sw.ElapsedMilliseconds} ms");
        sw.Restart();
        for (int i = 0; i < 1_000_000; i++)
        {
            nameDynamic = expando.Name;
            ageDynamic = expando.Age;
        }
        sw.Stop();
        Console.WriteLine($"dynamic(ExpandoObject)のプロパティアクセス時間: {sw.ElapsedMilliseconds} ms");
    }
}

静的型付けのプロパティアクセス時間: 2 ms
dynamic(ExpandoObject)のプロパティアクセス時間: 52 ms

ExpandoObjectのプロパティアクセスは静的型付けの約8倍遅くなっています。

ExpandoObjectは内部で辞書を使って動的にプロパティを管理しているため、アクセス時に辞書検索が発生し、dynamicの実行時バインディングと合わせてオーバーヘッドが大きくなります。

このように、データバインド用にdynamicやExpandoObjectを使う場合は、パフォーマンスと柔軟性のバランスを考慮して設計することが重要です。

パフォーマンス測定のすすめ

Stopwatch計測の基本

C#で簡単にパフォーマンスを測定するには、System.Diagnostics.Stopwatchクラスを使う方法が一般的です。

Stopwatchは高精度なタイマーで、処理の開始から終了までの経過時間をミリ秒単位で計測できます。

基本的な使い方は以下の通りです。

Stopwatchのインスタンスを作成し、Start()で計測を開始します。
計測したい処理を実行します。
Stop()で計測を終了し、ElapsedMillisecondsやElapsedTicksで経過時間を取得します。

以下は、dynamic型と静的型のメソッド呼び出し時間を計測する例です。

using System;
using System.Diagnostics;
class Sample
{
    public void DoWork() { /* 何らかの処理 */ }
}
class Program
{
    static void Main()
    {
        var sample = new Sample();
        dynamic dynamicSample = sample;
        var sw = new Stopwatch();
        // 静的型付けの計測
        sw.Start();
        for (int i = 0; i < 1_000_000; i++)
        {
            sample.DoWork();
        }
        sw.Stop();
        Console.WriteLine($"静的型付けの呼び出し時間: {sw.ElapsedMilliseconds} ms");
        // dynamic型の計測
        sw.Reset();
        sw.Start();
        for (int i = 0; i < 1_000_000; i++)
        {
            dynamicSample.DoWork();
        }
        sw.Stop();
        Console.WriteLine($"dynamic型の呼び出し時間: {sw.ElapsedMilliseconds} ms");
    }
}

静的型付けの呼び出し時間: 1 ms
dynamic型の呼び出し時間: 27 ms

Stopwatchは手軽に使えますが、計測結果は環境やCPU負荷によって変動しやすいため、複数回計測して平均を取るなどの工夫が必要です。

また、JITコンパイルの影響を考慮し、ウォームアップとして一度処理を実行してから計測を始めることも推奨されます。

BenchmarkDotNetによる詳細分析

より正確で詳細なパフォーマンス分析を行うには、BenchmarkDotNetという強力なベンチマークライブラリを使う方法があります。

BenchmarkDotNetは、JITのウォームアップやGCの影響を考慮し、統計的に信頼性の高い計測結果を提供します。

使い方は簡単で、ベンチマークしたいメソッドに[Benchmark]属性を付け、BenchmarkRunner.Run<T>()で実行します。

以下は、dynamic型と静的型のメソッド呼び出し速度を比較するサンプルです。

using System;
using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Running;
public class Sample
{
    public void DoWork() { }
}
public class DynamicVsStaticBenchmark
{
    private Sample sample = new Sample();
    private dynamic dynamicSample;
    public DynamicVsStaticBenchmark()
    {
        dynamicSample = sample;
    }
    [Benchmark]
    public void StaticCall()
    {
        sample.DoWork();
    }
    [Benchmark]
    public void DynamicCall()
    {
        dynamicSample.DoWork();
    }
}
class Program
{
    static void Main()
    {
        var summary = BenchmarkRunner.Run<DynamicVsStaticBenchmark>();
    }
}