【C#】LINQをAsParallelで高速化するPLINQ入門：順序制御とパフォーマンス最適化のポイント

LINQにAsParallelを付けるだけでクエリをマルチコアに分散できるのがPLINQです。

副作用のない関数と相性が良く、順序が不要なら単純なWhereやSelectだけでも大幅に高速化が期待できます。

順序保持が必要な場合はAsOrderedやAsSequentialで制御できます。

粒度が小さ過ぎたり同期が多い処理は逆に遅くなるため、導入前にベンチマークを行うと安心です。

PLINQの全体像

LINQとPLINQの位置付け

同期LINQの限界

C#のLINQ(Language Integrated Query)は、コレクションや配列などのデータソースに対して直感的にクエリを記述できる機能です。

例えば、WhereやSelectなどのメソッドを使って、データの抽出や変換を簡潔に書けるため、コードの可読性が大幅に向上します。

しかし、LINQは基本的に同期的に処理を行います。

つまり、クエリの各要素は1つのスレッドで順番に処理されるため、大量のデータを扱う場合や計算コストの高い処理を行う場合、処理時間が長くなりがちです。

特にマルチコアCPUが普及している現代の環境では、単一スレッドでの処理はCPUリソースを十分に活用できないことが多いです。

このような同期LINQの限界を補うために、並列処理を取り入れたPLINQ(Parallel LINQ)が登場しました。

PLINQは、LINQのクエリを複数のスレッドで同時に実行し、処理を高速化することを目的としています。

並列実行モデルの概要

PLINQは、LINQの拡張としてAsParallel()メソッドを提供し、これを呼び出すことでクエリの実行を並列化します。

内部的には、複数のスレッドに処理を分散し、各スレッドがデータの一部を担当して処理を行います。

処理が完了したら結果を統合し、最終的な出力を生成します。

この並列実行モデルにより、CPUの複数コアを活用して処理を分散できるため、特に大量のデータや計算負荷の高い処理でパフォーマンスの向上が期待できます。

ただし、並列化にはオーバーヘッドも存在するため、すべてのケースで高速化が保証されるわけではありません。

データ量や処理内容に応じて適切に使い分けることが重要です。

マルチコア活用の仕組み

タスクスケジューラとワークスティーリング

PLINQの並列処理は、.NETのタスク並列ライブラリ(TPL)を基盤にしています。

TPLは、複数のタスクを効率的にスケジューリングし、CPUの複数コアに負荷を分散する仕組みを提供します。

特に重要なのが「ワークスティーリング」というアルゴリズムです。

これは、各スレッドが自分のタスクキューから仕事を取り出して処理し、もし自分のキューが空になった場合は他のスレッドのキューからタスクを盗んで処理を続ける仕組みです。

これにより、スレッド間の負荷バランスが自動的に調整され、CPUリソースを最大限に活用できます。

PLINQはこのタスクスケジューラとワークスティーリングを活用して、データの分割と処理を効率的に行い、並列処理のパフォーマンスを最適化しています。

IParallelQueryインターフェース

PLINQのクエリは、IParallelQuery<T>インターフェースを通じて表現されます。

これはLINQのIEnumerable<T>に似ていますが、並列処理に特化した機能を持っています。

AsParallel()を呼び出すと、元のデータソース(例えば配列やリスト)からIParallelQuery<T>が生成されます。

このインターフェースは、並列クエリの構築や実行に必要なメソッドを提供し、WhereやSelectなどのLINQメソッドを並列版として利用可能にします。

また、IParallelQuery<T>は、並列処理の度合いや順序制御、キャンセルなどのオプションを設定するための拡張メソッドもサポートしています。

これにより、開発者は柔軟に並列処理の挙動をカスタマイズできます。

以上のように、PLINQはLINQの使いやすさを保ちつつ、マルチコアCPUの性能を活かして処理を高速化するための強力なツールです。

AsParallelの基本操作

AsParallelの呼び出し方

拡張メソッドとしてのAsParallel

AsParallel()はLINQの拡張メソッドの一つで、任意のIEnumerable<T>型のデータソースに対して呼び出すことができます。

これにより、その後のLINQクエリが並列で実行されるようになります。

System.Linq名前空間に含まれており、特別な準備なしに利用可能です。

例えば、配列やリストに対してAsParallel()を呼び出すだけで、簡単に並列クエリに切り替えられます。

以下のように記述します。

int[] numbers = Enumerable.Range(1, 1000).ToArray();
var parallelQuery = numbers.AsParallel();

この時点でparallelQueryはParallelQuery<int>型となり、LINQのメソッドチェーンを並列処理として実行します。

クエリ式への適用タイミング

AsParallel()はクエリの最初に適用するのが基本です。

データソースに対して直接呼び出すことで、その後のWhereやSelectなどの演算子が並列化されます。

例えば、以下のように書くと、WhereとSelectの両方が並列で処理されます。

var result = numbers.AsParallel()
                    .Where(n => n % 2 == 0)
                    .Select(n => n * 2);

一方で、途中でAsSequential()を挟むと、その後の処理は同期的に実行されます。

つまり、AsParallel()は並列化の開始点、AsSequential()は並列化の終了点を示す役割を持ちます。

クエリ構築から取得までの流れ

フィルタリング Where

Whereは条件に合致する要素だけを抽出する演算子です。

PLINQでは、AsParallel()で並列化されたクエリに対してWhereを適用すると、複数のスレッドがデータの異なる部分を同時に走査し、条件を満たす要素を抽出します。

例えば、以下のコードは1から1000までの数値のうち偶数だけを抽出します。

var evenNumbers = numbers.AsParallel()
                         .Where(n => n % 2 == 0)
                         .ToArray();

この処理は複数スレッドで分割して実行されるため、大量データのフィルタリングが高速化されます。

変換 Select

Selectは各要素を別の形に変換する演算子です。

PLINQの並列クエリにおいても、Selectは各スレッドが担当する要素に対して独立して変換処理を行います。

例えば、偶数の数値を2倍に変換する場合は以下のように書きます。

var doubledEvens = numbers.AsParallel()
                          .Where(n => n % 2 == 0)
                          .Select(n => n * 2)
                          .ToArray();

このように、Whereで絞り込んだ後にSelectで変換を行う処理も並列で効率的に実行されます。

結果集約 ToArray・ToList

PLINQのクエリは遅延実行されるため、実際に処理が走るのは結果を取得する操作を呼んだときです。

代表的な集約メソッドとしてToArray()やToList()があります。

これらのメソッドは、並列で処理された結果を一つの配列やリストにまとめて返します。

例えば、

var resultArray = numbers.AsParallel()
                         .Where(n => n % 2 == 0)
                         .ToArray();

この時点で並列処理が実行され、結果が配列として取得されます。

ToList()も同様に動作し、結果をList<T>として返します。

どちらを使うかは用途に応じて選択してください。

以下に、AsParallel()を使った基本的なサンプルコードを示します。

using System;
using System.Linq;
class Program
{
    static void Main()
    {
        // 1から1000までの数値を生成
        int[] numbers = Enumerable.Range(1, 1000).ToArray();
        // 並列で偶数を抽出し、2倍に変換して配列に格納
        var processedNumbers = numbers.AsParallel()
                                     .Where(n => n % 2 == 0)  // 偶数だけ抽出
                                     .Select(n => n * 2)      // 2倍に変換
                                     .ToArray();
        Console.WriteLine($"処理結果の要素数: {processedNumbers.Length}");
        Console.WriteLine("最初の5要素:");
        foreach (var num in processedNumbers.Take(5))
        {
            Console.WriteLine(num);
        }
    }
}

処理結果の要素数: 500
最初の5要素:
4
8
12
16
20

このコードでは、AsParallel()を使ってnumbers配列の偶数を並列に抽出し、さらに2倍に変換しています。

最後にToArray()で結果を配列として取得し、要素数と最初の5つの値を表示しています。

複数スレッドで処理されるため、大量データでも高速に処理できます。

順序制御の要点

非順序実行の既定動作

PLINQはデフォルトで非順序(順序を保証しない)でクエリを実行します。

これは、元のデータソースの順序を維持せずに、複数のスレッドで自由に要素を処理し、結果をまとめる方式です。

非順序実行はパフォーマンスを最大化するための設計であり、スレッド間の同期やバッファリングを最小限に抑えられます。

早期合流のメリット・デメリット

非順序実行の大きなメリットは「早期合流(early merge)」が可能なことです。

これは、各スレッドが処理した結果をすぐに出力に渡せるため、全体の処理が完了するのを待たずに部分的な結果を返せることを指します。

これにより、メモリ使用量が抑えられ、処理のスループットが向上します。

一方で、順序が保証されないため、元のデータの並び順が重要な場合には適しません。

例えば、ログの時系列処理やユーザーインターフェースでの表示順序が必要なケースでは、非順序実行は不適切です。

また、結果の順序がバラバラになるため、後続の処理で順序を前提としたロジックがある場合は注意が必要です。

AsOrderedで順序保持

AsOrdered()メソッドを使うと、PLINQのクエリで元のデータソースの順序を保持したまま並列処理が行えます。

これにより、結果の列挙時に元の順序が保証されるため、順序依存の処理に対応可能です。

内部バッファリングの発生

順序を保持するためには、PLINQは各スレッドの処理結果を一時的にバッファに蓄積し、元の順序に従って結果を出力します。

この内部バッファリングは、処理の完了を待つ必要があるため、非順序実行に比べて遅延が発生しやすくなります。

例えば、あるスレッドの処理が遅れている場合、他のスレッドの結果が先に完了していても、順序を保つために待機しなければなりません。

このため、AsOrdered()を使うとパフォーマンスが低下する可能性があります。

処理コストとのトレードオフ

AsOrdered()は順序保証とパフォーマンスのトレードオフを意味します。

順序が重要な場合はAsOrdered()を使うべきですが、パフォーマンスを優先したい場合は非順序実行を選択したほうが良いです。

実際の開発では、順序が必要な部分だけAsOrdered()を使い、他は非順序で処理するなど、適切に使い分けることが効果的です。

AsSequentialで逐次へ戻す

AsSequential()はPLINQの並列クエリを途中で逐次(同期)処理に戻すためのメソッドです。

これにより、並列処理の途中から順序を保証しつつ、同期的に処理を続けることができます。

部分並列化の戦略パターン

部分的に並列化し、必要な箇所で逐次処理に切り替える戦略は、複雑な処理フローでよく使われます。

例えば、データのフィルタリングや変換は並列で高速に行い、最終的な集約や順序依存の処理はAsSequential()で同期的に行うケースです。

以下の例では、並列でフィルタリングした後、逐次処理で順序を保ちながら結果を処理しています。

var query = data.AsParallel()
                .Where(x => x.IsValid)
                .AsSequential()
                .Select(x => ProcessSequentially(x));

このように、AsSequential()を使うことで、並列処理のメリットを活かしつつ、順序や副作用の管理が必要な部分を安全に処理できます。

OrderByとの違いと使い分け

OrderByはLINQの標準的な並べ替え演算子で、要素を指定したキーに基づいて昇順または降順にソートします。

PLINQでもOrderByは利用可能ですが、AsOrdered()とは役割が異なります。

AsOrdered()は元のデータの順序を保持するためのものであり、ソートは行いません。

一方、OrderByは明示的にキーに基づくソートを行い、結果の順序を変えます。

キー比較コストの影響

OrderByはキーの比較処理が必要なため、キーの計算や比較コストが高い場合はパフォーマンスに影響します。

PLINQでは並列でソート処理を行いますが、ソート自体は比較的コストの高い操作です。

そのため、単に元の順序を保ちたい場合はAsOrdered()を使い、特定のキーで並べ替えたい場合はOrderByを使うのが適切です。

両者を組み合わせることも可能ですが、パフォーマンスと目的に応じて使い分けることが重要です。

パフォーマンス最適化のポイント

ワークロード粒度の見極め

小粒タスクが遅くなる理由

PLINQでの並列処理は、処理対象のデータを複数のタスクに分割して同時に実行します。

しかし、タスクの粒度が小さすぎると、並列化のオーバーヘッドが処理時間を上回り、かえって遅くなることがあります。

具体的には、タスクの分割やスレッド間の同期、コンテキストスイッチングなどのコストが発生します。

これらのオーバーヘッドは、処理単位が小さいほど相対的に大きくなり、結果として全体のパフォーマンスが低下します。

例えば、単純な計算や短時間で終わる処理を大量に細かく分割すると、スレッドの切り替えやタスク管理にかかる時間が無視できなくなります。

こうした小粒タスクは、並列化の恩恵を受けにくいので注意が必要です。

コスト測定の目安

ワークロードの粒度を適切に設定するためには、処理時間の計測が重要です。

一般的には、1つのタスクが数ミリ秒以上かかる処理であれば、並列化の効果が期待できます。

具体的には、Stopwatchクラスなどを使って処理時間を計測し、単一スレッドでの処理時間と並列処理のオーバーヘッドを比較します。

もし並列化によるオーバーヘッドが処理時間の半分以上を占める場合は、タスクの粒度を大きくするか、並列化を見直すべきです。

WithDegreeOfParallelismの調整

CPUコア数とスレッド数

WithDegreeOfParallelismメソッドは、PLINQの並列度(同時に実行するタスクの最大数)を制御します。

デフォルトでは、環境の論理プロセッサ数に基づいて自動設定されますが、明示的に制限することも可能です。

CPUコア数に合わせて並列度を設定するのが基本で、例えば4コアのCPUならWithDegreeOfParallelism(4)と指定します。

これにより、過剰なスレッド生成を防ぎ、CPUリソースの競合を抑えられます。

ただし、CPUコア数より多く設定すると、スレッドの切り替えが頻繁になり、逆にパフォーマンスが低下することがあります。

逆に少なすぎるとCPUリソースを十分に活用できません。

IOバウンド処理の例

CPUバウンド処理とは異なり、IOバウンド処理(ファイルアクセスやネットワーク通信など)はCPU待ち時間が多いため、CPUコア数以上の並列度を設定しても効果的な場合があります。

例えば、ディスク読み込みやWeb API呼び出しを含む処理では、WithDegreeOfParallelismをCPUコア数の2倍や3倍に設定しても、待機時間を有効活用できるためスループットが向上します。

ただし、IOリソースの制限やスレッド数の増加によるメモリ消費増加には注意が必要です。

MergeOptionsによるマージ戦略

PLINQは複数スレッドで処理した結果を最終的に1つのシーケンスにまとめます。

このマージ処理の方法はMergeOptionsで制御可能です。

NotBuffered

MergeOptions.NotBufferedは、各スレッドの処理結果をバッファリングせずに、できるだけ早く結果を返すモードです。

これにより、結果の出力が早く始まり、メモリ使用量も抑えられます。

ただし、順序保証がないため、結果の順序がバラバラになることがあります。

リアルタイム性が求められる処理や、順序が不要な場合に適しています。

AutoBuffered

MergeOptions.AutoBufferedはデフォルトの動作で、適度にバッファリングを行いながら結果を返します。

バッファリングにより順序の一部保持や効率的なマージが可能ですが、メモリ使用量はNotBufferedより多くなります。

多くの一般的なケースでバランスの良い選択肢です。

FullyBuffered

MergeOptions.FullyBufferedは、すべてのスレッドの処理が完了するまで結果をバッファにため込み、完了後にまとめて返します。

これにより、順序保証が強化され、後続の処理で順序依存のロジックが安全に行えます。

ただし、メモリ使用量が増加し、結果の出力開始が遅れるため、リアルタイム性が求められる処理には不向きです。

Early Exitとキャンセル

WithCancellationによるトークン連携

PLINQはWithCancellationメソッドを使って、CancellationTokenと連携し、処理の途中でキャンセルを受け付けられます。

これにより、ユーザー操作やタイムアウトなどの理由で処理を中断可能です。

var cts = new CancellationTokenSource();
var query = data.AsParallel()
                .WithCancellation(cts.Token)
                .Where(x => HeavyComputation(x));

キャンセルトークンが発行されると、PLINQはできるだけ早く処理を中断し、OperationCanceledExceptionをスローします。

これをキャッチして適切に処理を終了させます。

BreakとStopの挙動差

PLINQにはParallelLoopStateのBreakとStopに似た機能があり、ForAllなどのループ内で早期終了を指示できます。

• Breakは現在の最小インデックスより大きい要素の処理を中止します。つまり、処理の順序を考慮し、後続の要素の処理を止める指示です
• Stopはすべての要素の処理をできるだけ早く中止します。順序に関係なく即座に処理を終了させたい場合に使います

これらはキャンセルとは異なり、ループ内の制御フローとして機能します。

適切に使い分けることで、無駄な処理を減らしパフォーマンスを向上させられます。

副作用とスレッドセーフティ

共有状態の危険性

競合条件とデータ破壊

PLINQを使った並列処理では、複数のスレッドが同時にデータを操作するため、共有状態の管理が非常に重要になります。

共有状態とは、複数のスレッドからアクセスされる変数やオブジェクトの状態のことです。

もし共有状態に対して適切な同期処理を行わずに読み書きをすると、競合条件(レースコンディション)が発生します。

これは、複数のスレッドが同時に同じデータを変更しようとして、予期しない結果やデータ破壊が起こる現象です。

例えば、複数のスレッドが同じリストに要素を追加する処理を同期なしで行うと、内部のデータ構造が破損し、例外が発生したり、データが欠落したりします。

var sharedList = new List<int>();
var numbers = Enumerable.Range(1, 1000);
numbers.AsParallel().ForAll(n =>
{
    // 共有リストに同期なしで追加すると危険
    sharedList.Add(n);
});

このコードはスレッドセーフではなく、実行時に例外が発生したり、結果が不正確になる可能性があります。

共有状態を扱う場合は、lock文やConcurrentコレクションなどのスレッドセーフな手段を使う必要があります。

不変オブジェクトの活用

コピー回数とメモリ負荷

副作用を避けるために、不変(イミュータブル)オブジェクトを活用する方法があります。

不変オブジェクトは生成後に状態が変わらないため、複数スレッドから安全に共有できます。

PLINQの並列処理では、各スレッドが独立してデータを処理し、不変オブジェクトを使うことで共有状態の競合を回避できます。

例えば、文字列やSystem.Tuple、System.ValueTupleは不変オブジェクトの代表例です。

ただし、不変オブジェクトを多用すると、コピーや新規生成が頻繁に発生し、メモリ使用量が増加することがあります。

特に大きなデータ構造を不変化すると、GC(ガベージコレクション)の負荷が高まる可能性があるため注意が必要です。

不変オブジェクトの利用は、スレッドセーフティとパフォーマンスのバランスを考慮しながら設計することが重要です。

必要に応じて、部分的に不変化したデータ構造や、スレッドローカルなコピーを使うなどの工夫も有効です。

例外処理の実践

AggregateExceptionの構造

PLINQで並列処理を行う際、複数のスレッドで同時に例外が発生する可能性があります。

こうした場合、PLINQは例外をまとめてAggregateExceptionとしてスローします。

AggregateExceptionは複数の例外を内包できる特殊な例外クラスです。

AggregateExceptionの主な特徴は、InnerExceptionsプロパティに複数の例外オブジェクトを保持している点です。

これにより、どのスレッドでどのような例外が発生したかを詳細に把握できます。

InnerExceptionsの列挙

AggregateExceptionのInnerExceptionsはReadOnlyCollection<Exception>型で、複数の例外を列挙可能です。

例外処理時には、このコレクションをループで回して個別の例外を確認・処理します。

以下は、PLINQの例外をキャッチしてInnerExceptionsを列挙する例です。

using System;
using System.Linq;
class Program
{
    static void Main()
    {
        int[] numbers = { 1, 2, 0, 4, 5 };
        try
        {
            var results = numbers.AsParallel()
                                 .Select(n => 10 / n)  // 0除算で例外発生
                                 .ToArray();
        }
        catch (AggregateException ex)
        {
            Console.WriteLine("AggregateExceptionが発生しました。詳細:");
            foreach (var innerEx in ex.InnerExceptions)
            {
                Console.WriteLine($"例外タイプ: {innerEx.GetType().Name}, メッセージ: {innerEx.Message}");
            }
        }
    }
}

AggregateExceptionが発生しました。詳細:
例外タイプ: DivideByZeroException, メッセージ: Attempted to divide by zero.

このように、AggregateExceptionをキャッチしてInnerExceptionsを列挙することで、複数の例外を個別に把握できます。

回復・リトライパターン

PLINQの並列処理で例外が発生した場合、単に例外をキャッチしてログを残すだけでなく、回復やリトライを行うこともあります。

特にIO操作や外部サービス呼び出しなど、失敗が一時的な場合に有効です。

回復・リトライの基本的なパターンは、例外が発生した要素だけを再処理する方法です。

PLINQのクエリ内で例外を捕捉し、失敗した要素を別途収集して後から再試行します。

以下は、例外を内部でキャッチして失敗した要素をリストに追加し、後でリトライする例です。

using System;
using System.Collections.Concurrent;
using System.Linq;
class Program
{
    static void Main()
    {
        int[] numbers = { 1, 2, 0, 4, 5 };
        var failedItems = new ConcurrentBag<int>();
        var results = numbers.AsParallel()
                             .Select(n =>
                             {
                                 try
                                 {
                                     return 10 / n;
                                 }
                                 catch (DivideByZeroException)
                                 {
                                     failedItems.Add(n);
                                     return -1;  // エラー時のデフォルト値
                                 }
                             })
                             .ToArray();
        Console.WriteLine("処理結果:");
        foreach (var r in results)
        {
            Console.WriteLine(r);
        }
        if (failedItems.Count > 0)
        {
            Console.WriteLine("リトライ対象の要素:");
            foreach (var item in failedItems)
            {
                Console.WriteLine(item);
            }
            // リトライ処理(例として単純にスキップ)
            // 実際にはリトライロジックをここに実装
        }
    }
}

処理結果:
10
5
-1
2
2
リトライ対象の要素:
0

この例では、0除算が発生した要素をfailedItemsに記録し、後でリトライ対象として扱っています。

リトライ処理はケースに応じて実装してください。

また、リトライ回数の制限や指数的バックオフなどの高度な制御を組み合わせることで、より堅牢なエラーハンドリングが可能です。

PLINQの例外処理は、単純なキャッチだけでなく、こうした回復戦略を組み込むことで実用的な並列処理を実現できます。

デバッグとプロファイリング

Visual Studio Parallel Stacks

Visual Studioには並列処理のデバッグを支援する「Parallel Stacks」ウィンドウがあります。

PLINQのような並列クエリを実行している際に、複数のスレッドのスタックトレースを視覚的に確認できるため、どのスレッドがどの処理を実行しているかを把握しやすくなります。

Parallel Stacksは、スレッドの呼び出し階層をツリー状に表示し、スレッド間の関係や並列処理の進行状況を直感的に理解できます。

特にデッドロックや競合状態の調査、処理のボトルネック特定に役立ちます。

PLINQのクエリ内で例外が発生した場合や、処理が遅延している箇所を特定したいときに、Parallel Stacksを使ってスレッドの状態を詳細に追跡すると効果的です。

Diagnostic ToolsでのCPU計測

Visual StudioのDiagnostic Toolsは、アプリケーションのCPU使用率やメモリ消費をリアルタイムで計測できる強力なツールです。

PLINQの並列処理がCPUリソースをどの程度使っているかを把握し、パフォーマンスの最適化に役立てられます。

スレッドタイムライン解析

Diagnostic Toolsの「CPU Usage」タブでは、スレッドごとのCPU使用時間をタイムライン形式で表示します。

これにより、どのスレッドがいつCPUを使っていたか、並列処理の負荷分散が適切かどうかを視覚的に確認できます。

例えば、PLINQの並列度が高すぎてスレッドが過剰に生成されている場合や、逆に一部のスレッドに負荷が集中している場合に気づけます。

スレッドのアイドル時間やコンテキストスイッチの頻度も把握できるため、スレッド管理の改善点を見つけやすくなります。

また、特定の処理がCPUを長時間占有している場合は、そのコード部分を特定して最適化を検討できます。

ETW・EventSourceの活用

ETW(Event Tracing for Windows)とEventSourceは、.NETアプリケーションの詳細なイベントトレースを取得するための仕組みです。

PLINQの並列処理に関する詳細な動作ログを収集し、パフォーマンス解析や問題の原因調査に活用できます。

EventSourceを使うと、独自のイベントをアプリケーション内で発行でき、ETWトレースと組み合わせて高精度なログ収集が可能です。

PLINQの内部動作やスレッドの状態、処理の開始・終了タイミングなどをカスタムイベントとして記録し、後から詳細に分析できます。

ETWトレースはWindowsの標準ツールやVisual Studioの診断機能、PerfViewなどの専用ツールで解析可能です。

これにより、PLINQのパフォーマンスボトルネックやスレッド競合、リソース使用状況を深く掘り下げられます。

これらのツールを組み合わせて使うことで、PLINQの並列処理の挙動を詳細に把握し、効率的なデバッグとパフォーマンスチューニングが実現します。

ケーススタディ

大規模データフィルタリング

配列 vs List<T> の比較

大量のデータから条件に合致する要素を抽出するフィルタリング処理は、PLINQの得意分野です。

ここでは、配列T[]とリストList<T>を対象にしたフィルタリングのパフォーマンス差を見てみます。

配列はメモリ上で連続した領域に格納されているため、アクセスが高速でキャッシュ効率が良い特徴があります。

一方、List<T>は内部的に配列を使っていますが、サイズ変更や要素追加の柔軟性があるため、若干のオーバーヘッドがあります。

以下のサンプルでは、1,000万件の整数データから偶数を抽出する処理をPLINQで実行し、配列とリストでの処理時間を比較します。

using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Linq;
class Program
{
    static void Main()
    {
        const int dataSize = 10_000_000;
        int[] arrayData = Enumerable.Range(1, dataSize).ToArray();
        List<int> listData = new List<int>(arrayData);
        var sw = new Stopwatch();
        // 配列でのPLINQフィルタリング
        sw.Start();
        var evenArray = arrayData.AsParallel()
                                 .Where(n => n % 2 == 0)
                                 .ToArray();
        sw.Stop();
        Console.WriteLine($"配列の処理時間: {sw.ElapsedMilliseconds} ms");
        sw.Reset();
        // リストでのPLINQフィルタリング
        sw.Start();
        var evenList = listData.AsParallel()
                               .Where(n => n % 2 == 0)
                               .ToList();
        sw.Stop();
        Console.WriteLine($"リストの処理時間: {sw.ElapsedMilliseconds} ms");
    }
}

配列の処理時間: 90 ms
リストの処理時間: 147 ms

この結果から、配列の方がわずかに高速であることがわかります。

大規模データの並列処理では、メモリの連続性がパフォーマンスに影響するため、可能な限り配列を使うことが推奨されます。

イメージ処理パイプライン

ピクセル分散処理の例

画像処理では、各ピクセルに対して独立した計算を行うことが多く、PLINQの並列処理が効果的です。

ここでは、画像の輝度を調整する簡単な例を示します。

画像は2次元配列や1次元配列で表現されることが多いですが、PLINQでは1次元配列に変換して処理するのが一般的です。

各ピクセルの輝度値を一定の係数で乗算し、明るさを調整します。

using System;
using System.Linq;
class Program
{
    static void Main()
    {
        int width = 1920;
        int height = 1080;
        byte[] pixels = new byte[width * height]; // グレースケール画像の輝度値
        // 仮に全ピクセルを中間輝度で初期化
        for (int i = 0; i < pixels.Length; i++)
        {
            pixels[i] = 128;
        }
        double brightnessFactor = 1.2; // 明るさを20%アップ
        var adjustedPixels = pixels.AsParallel()
                                   .Select(p =>
                                   {
                                       int adjusted = (int)(p * brightnessFactor);
                                       return (byte)(adjusted > 255 ? 255 : adjusted);
                                   })
                                   .ToArray();
        Console.WriteLine($"最初の5ピクセルの輝度値: {string.Join(", ", adjustedPixels.Take(5))}");
    }
}

最初の5ピクセルの輝度値: 153, 153, 153, 153, 153

この例では、全ピクセルの輝度を並列に処理し、明るさを調整しています。

各ピクセルは独立して処理できるため、PLINQの並列化が非常に効果的です。

大規模な画像や動画処理でのパフォーマンス向上に役立ちます。

文字列検索高速化

正規表現並列実行の効果

大量のテキストデータから特定のパターンを検索する場合、正規表現(Regex)を使うことが多いですが、処理コストが高いことが課題です。

PLINQを使って複数のテキストを並列に検索することで、処理時間を大幅に短縮できます。

以下は、複数の文字列に対して正規表現マッチングを並列で行う例です。

using System;
using System.Linq;
using System.Text.RegularExpressions;
class Program
{
    static void Main()
    {
        string[] texts = Enumerable.Range(1, 10000)
                                   .Select(i => $"Sample text number {i} with some pattern 12345")
                                   .ToArray();
        Regex regex = new Regex(@"\d{5}");
        var matches = texts.AsParallel()
                           .Where(text => regex.IsMatch(text))
                           .ToArray();
        Console.WriteLine($"マッチした文字列数: {matches.Length}");
    }
}

マッチした文字列数: 10000

この例では、すべての文字列に5桁の数字が含まれているため、すべてマッチします。

PLINQにより複数スレッドで同時に検索を行うため、単一スレッドで処理するよりも高速に完了します。

正規表現のマッチングはCPU負荷が高いため、PLINQの並列化効果が特に顕著です。

ただし、正規表現オブジェクトはスレッドセーフである必要があるため、Regexのインスタンスは共有して使うことが推奨されます。

よくある落とし穴

GCプレッシャー増大

PLINQを使った並列処理では、多数のスレッドが同時に処理を行うため、一時的に大量のオブジェクトが生成されることがあります。

特にSelectやWhereなどの変換・フィルタリング処理で新しいオブジェクトを頻繁に作成すると、ガベージコレクション(GC)の負荷が増大します。

GCプレッシャーが高まると、頻繁にGCが発生し、アプリケーションのパフォーマンスが低下します。

特に大規模データを扱う場合や短時間に大量のオブジェクトを生成する処理では注意が必要です。

対策としては、可能な限り不必要なオブジェクト生成を避けること、値型の利用やキャッシュの活用、Span<T>やMemory<T>などのメモリ効率の良い構造を使うことが挙げられます。

また、PLINQのバッファリング設定を調整し、メモリ使用量を抑えることも効果的です。

メモリ帯域の飽和

PLINQはCPUの複数コアを活用して高速化を図りますが、メモリ帯域がボトルネックになるケースがあります。

特に大量のデータを頻繁に読み書きする処理では、CPUが高速でもメモリの読み書き速度が追いつかず、全体の処理速度が頭打ちになります。

このメモリ帯域の飽和は、並列度を上げすぎることで顕著になります。

多くのスレッドが同時にメモリにアクセスすると、帯域幅が限界に達し、スレッド間で競合が発生します。

対策としては、並列度の適切な調整や、データアクセスパターンの最適化、キャッシュ効率の向上が重要です。

例えば、データを局所性の高い単位に分割し、スレッドごとに独立したメモリ領域を使う工夫が有効です。

並列化が逆効果になる条件

PLINQの並列化は万能ではなく、場合によっては逆効果になることがあります。

以下のような条件では、並列化によるオーバーヘッドが処理時間を上回り、パフォーマンスが低下します。

• 処理が非常に軽量で短時間の場合

タスクの分割やスレッド管理のコストが大きくなり、単一スレッドで処理した方が速いことがあります。

• データ量が少ない場合

並列化の効果が出るほどのデータ量がないと、オーバーヘッドだけが増えます。

• 共有リソースへのアクセスが多い場合

ロックや同期処理が頻発すると、スレッドが待機状態になり、並列化のメリットが失われます。

• メモリ帯域やIOがボトルネックの場合

CPUが待機状態になるため、並列度を上げても効果が薄いです。

これらの条件を見極めるために、ベンチマークやプロファイリングを行い、実際の処理時間やリソース使用状況を確認することが重要です。

適切な粒度で並列化を行い、必要に応じて同期処理に戻す判断も必要です。

既存コードのPLINQ移行手順

候補箇所の見つけ方

プロファイラでのホットパス特定

PLINQを導入して既存コードのパフォーマンスを改善する際、まずは並列化の効果が期待できる処理箇所を特定することが重要です。

これにはプロファイラを活用して「ホットパス(処理時間が多くかかっている部分)」を見つける方法が有効です。

Visual StudioのプロファイラやJetBrains dotTrace、Redgate ANTS Profilerなどのツールを使い、アプリケーションを実行しながらCPU使用率やメソッドごとの実行時間を計測します。

これにより、どのメソッドやループがボトルネックになっているかを明確に把握できます。

特に、データの走査や変換、集約処理など、繰り返し大量の要素を処理している箇所がPLINQの並列化候補となります。

逆に、I/O待ちや外部リソースアクセスが多い部分は並列化の効果が薄いことが多いため、優先度は低くなります。

段階的導入アプローチ

ベンチマーク比較と回帰確認

PLINQの導入は一気に全コードを並列化するのではなく、段階的に進めることが推奨されます。

まずは特定のホットパスに絞ってAsParallel()を適用し、パフォーマンスの改善効果をベンチマークで測定します。

ベンチマークは、単純な処理時間の計測だけでなく、スレッド数やCPU使用率、メモリ消費量も含めて総合的に評価します。

これにより、並列化によるオーバーヘッドや副作用の有無を確認できます。

また、並列化によって動作の回帰(バグや性能低下)が起きていないか、ユニットテストや統合テストを実行して検証します。

特に副作用のある処理や共有状態を扱う部分は注意が必要です。

段階的に並列化範囲を広げ、都度ベンチマークとテストを繰り返すことで、安全かつ効果的にPLINQを既存コードに組み込めます。

これにより、パフォーマンス向上と品質維持の両立が可能になります。

代替・補完技術

Taskとasync/awaitとの棲み分け

Taskとasync/awaitは、C#における非同期プログラミングの基本的な仕組みであり、PLINQの並列処理とは異なる目的や使い方があります。

PLINQは主にCPUバウンドな大量データの並列処理に適していますが、Taskとasync/awaitはI/Oバウンド処理や非同期操作の管理に強みがあります。

例えば、ファイル読み書きやネットワーク通信など、待機時間が発生する処理ではasync/awaitを使ってスレッドをブロックせずに効率的にリソースを利用できます。

一方、PLINQはCPUコアをフル活用して計算処理を高速化するため、CPU負荷の高い処理に向いています。

両者は補完関係にあり、以下のように使い分けるのが一般的です。

• CPUバウンド処理: PLINQやTask.Runで並列化し、複数コアを活用して高速化します
• I/Oバウンド処理: async/awaitで非同期に処理し、スレッドの無駄な待機を減らす

また、TaskはPLINQの内部でも利用されており、必要に応じてTaskベースのAPIと組み合わせて使うことも可能です。

例えば、PLINQで並列処理した結果をTaskでラップして非同期に扱うケースなどがあります。

System.Threading.Tasks.Dataflowとの比較

System.Threading.Tasks.Dataflow(以下Dataflow)は、TPL(Task Parallel Library)の一部であり、データフロー型の並列処理を実現するためのライブラリです。

Dataflowはパイプライン処理や非同期メッセージングに適しており、複雑な処理の分割やステージ間の非同期連携を簡単に構築できます。

PLINQは主にコレクションに対する並列クエリ処理に特化しているのに対し、Dataflowは以下のような特徴があります。

• 柔軟なパイプライン構築: 複数の処理ブロック(TransformBlock、BufferBlockなど)を組み合わせて、データの流れを制御できます
• 非同期処理の自然なサポート: 各ブロックは非同期に動作し、バックプレッシャーやキャンセルも管理しやすい
• メッセージ駆動型: データをメッセージとして扱い、複雑な依存関係や条件付き処理を表現可能です

一方、PLINQは単純なデータセットに対して高速に並列クエリを実行するのに適しており、Dataflowのような複雑なパイプライン制御は苦手です。

使い分けのポイントは以下の通りです。

まとめると、CPUバウンドの単純な並列処理にはPLINQが手軽で効果的ですが、複雑な非同期パイプラインやメッセージ駆動の処理にはDataflowが適しています。

用途や処理の性質に応じて使い分けることが重要です。

まとめ

この記事では、C#のPLINQを使った並列処理の基本から順序制御、パフォーマンス最適化、例外処理、デバッグ手法、ケーススタディ、よくある落とし穴、既存コードへの導入手順、そして代替技術との使い分けまで幅広く解説しました。

PLINQは大量データのCPUバウンド処理を効率化しますが、適切な粒度設定や順序制御、副作用の管理が重要です。

パフォーマンス向上と安全性を両立させるためのポイントを理解し、実践的に活用できる知識が身につきます。