Optimizing XamDataGrid Performance Using External Data Operations

すべての業界でXamDataGridの使用が絶えず発展しているとすれば、それは XamDataGridに表示されるデータ量の増加です。従来、グリッド コントロールは、並べ替え、フィルター処理、グループ化などのデータ操作を UI スレッドで単独で実行します。ただし、データ負荷が増加するにつれて、開発者はこれらの操作を別のスレッドで実行する方法、またはまったく別のマシンで実行する方法を探しています。そのため、開発者からは、XamDataGridにこれらの操作の引数を渡させ、この操作を実行せずに処理結果を表示するように依頼されました。12.1 リリースでこの機能が追加され、大規模なデータセットがXamDataGridにバインドされている場合のパフォーマンスが大幅に向上しました。このブログ記事では、この機能を利用する方法と、メモリ フットプリントと操作の実行にかかる時間の観点から、パフォーマンスへの影響について説明します。

​サンプルプロジェクトをダウンロードしてください - データ操作のオフグリッド処理をアクティブにする方法を示し、内部操作と外部操作が使用される場合の2つのケースで、同じデータセットにバインドされたXamDataGridのパフォーマンスを比較します。プロジェクトは、Visual Studio 2010 と .NET Framework 4 を使用してビルドされます。12.1 WPF 製品の試用版を使用しているため、追加のダウンロードなしでビルドして実行できます。XamDataGridを含むNetAdvantage for WPF製品のフル機能の30日間の無料試用版​が利用可能です。サンプル プロジェクトのスクリーンショットを次に示します。

サンプルの内容

サンプル アプリケーションでは、2 つの XamDataGrid が並んでおり、左側の 1 つは内部操作を使用し、右側の 1 つは代わりに CollectionView オブジェクトを介してこれらの操作を実行します。両方のグリッドは、100,000 レコードを含むデータセットにバインドされています。内部操作と外部操作によるパフォーマンスの違いを説明するために、並べ替えとグループ化のパフォーマンスを比較します。ただし、まったく同じ結果がフィルタリングとサマリー計算にも適用されます。

内部ソート/グループの使用によるパフォーマンスへの影響

デフォルトでは、XamDataGrid は、(データセット内のすべてのレコードではなく) 現在表示されているデータ項目を表すレコードオブジェクトのみを作成します。ただし、ソート/グループ化操作が XamDataGrid によって内部的に実行される場合は、データ セット内のすべての項目を表すレコード オブジェクトを作成して、それらを並べ替え/グループ化できるようにする必要があります。XamDataGrid UI 仮想化ロジックにより、これらすべてのレコードに対して UI 要素が作成されるわけではありませんが、特に XamDataGrid にバインドされたデータセットが大きい場合は、レコード オブジェクトがアプリケーションのメモリ フットプリントに大きな影響を与える可能性があります (以下のパフォーマンス比較で説明します)。では、これはパフォーマンスにどのように影響するのでしょうか?ユーザーが初めてグリッドを並べ替えたりグループ化したりするときは、XamDataGrid がすべてのデータ項目のレコード オブジェクトを作成し、ユーザーが要求した操作を実行するのに遅延が発生します。これにより、XamDataGrid によって管理されるレコード オブジェクトに関して、データセット全体がメモリに格納されます。これにより、メモリ フットプリントが増加し、このような操作を初めて実行するときに遅延が発生しますが、データセット全体が既にメモリ内にあるため、後続の並べ替え/グループ化操作は非常に高速です。

これがパフォーマンスにどのように影響するかを見てみましょう。サンプルを実行し、左側にある XamDataGrids を並べ替えるかグループ化してください – その上に時間とメモリ フットプリントの変化 (デルタ) が表示されます。私のマシンでは、内部操作グリッドが初めて並べ替えられると、操作に 4.3 秒かかり、メモリ消費量が 40MB 増加します。その後のソートには約 1 秒かかり、メモリフットプリントは同じままです (すでに最大になっているため、すべてのデータ項目はレコードオブジェクトとして表されます)。データセットがすでに完全に読み込まれると、グループ化には約 2.8 秒かかり、グループ化解除には 1.2 秒かかります。

外部の並べ替え/グループを使用することによるパフォーマンスへの影響

並べ替え、グループ化、フィルター処理、および集計計算の実行方法は、SortEvaluationMode、GroupByEvaluationMode、FilterEvaluationMode、および SummaryEvaluationModeプロパティを使用して制御できます。これにより、内部の並べ替え、グループ化、フィルター処理、および集計計算を無効にし、それらを手動で実行するか、CollectionView オブジェクトを使用して実行することができます。つまり、グリッドはデータセット全体を表すためにレコードオブジェクトを初期化する必要がなく、代わりにバックエンドに依存してデータセットを並べ替えます。コレクション ビューを使用する場合 (上記のプロパティを "UseCollectionView" に設定する場合)、追加のロジックを実装する必要はありません。ただし、計算/並べ替えが実行されるバックエンドサーバーがある場合は、上記のプロパティの手動設定を使用できます。これにより、XamDataGrid はSorting / Grouping / RecordFilterChangingイベントを発生させ、これらをバックエンドに渡して計算を実行できるようになります。XamDataGridは、バックエンドによって処理されると、並べ替えられたデータセットを表示します。

並べ替え/グループ化に UseCollectionView 設定と Manual 設定を使用すると、XamDataGrid はデータセット全体のレコード オブジェクトをインスタンス化する必要がなくなり、メモリ フットプリントを常に低く抑えることができます。パフォーマンスの時間コンポーネントは、これらの操作の処理に使用しているバックエンドによって異なります。このサンプルでは、右側の XamDataGridで、内部ロジックの代わりに CollectionView オブジェクトを使用してこれらの操作を処理しています。

この場合、パフォーマンスはどうでしょうか?サンプルを実行し、右側でXamDataGridを並べ替えるかグループ化してください - 時間とメモリフットプリントの変更はすぐ上に報告されます。collectionView によって並べ替えとグループ化が実行される場合 (SortEvaluationMode プロパティと GroupByEvaluationMode プロパティの UseCollectionView 値を使用)、メモリ占有領域は同じままで、所要時間は 2.5 秒、4.9 秒のグループ化、2.5 秒のグループ化解除です。ここで言及すべき3つのポイントがあります。

1. ソート/グループ化によって追加のレコードオブジェクトがインスタンス化されないため、メモリフットプリントは一定に保たれます

2. ソート/グループ化にかかる時間は一定であり、つまり、最初のソート/グループ化を実行するときに大きな遅延はありません(レコードオブジェクトの初期化により内部操作が使用される場合など)

3. ソート/グループ化にかかる時間は、内部操作が使用されている場合に同じ操作を実行するのにかかる時間よりも長くなります。ただし、パフォーマンスの時間的側面は、これらの操作に使用するバックエンドに完全に依存しています。それでも、collectionView オブジェクトを使用すると、メモリ消費量が少なくなり、初回のソート/グループのパフォーマンスが向上します (ただし、内部操作の場合は、操作を初めて実行するときに追加の遅延が発生します) 。場合によっては役立つ場合があります。

Summary Calculations

デフォルトの内部集計計算では、グリッドがデータセット全体を表すレコードオブジェクトを初期化する必要があります。SummaryEvaluationModeプロパティを使用すると、Linq を使用して、または手動で集計計算を実行することもできます。Linq を使用する側で追加の実装は必要ありませんが、手動計算モードを使用するには、QuerySummaryResultイベントを処理する必要があります。そこでは、独自の評価ロジックを実行し、概要結果の値を指定できます。手動モードを使用すると、メモリ消費量を低く抑えることができ、バックエンドを最適化することで計算時間を可能な限り改善する機会が得られます。

概要

このブログ記事では、XamDataGridを設定して、外部で並べ替え/グループ化/フィルタリング/集計計算を実行する方法を紹介しました。この目的で使用する API について説明し、外部操作を使用した場合のパフォーマンスへの影響について調べました。サンプル プロジェクトを使用すると、2 つのシナリオの違いを簡単に示すことができ、独自のデータをバインドしたときに表示されるパフォーマンスの向上を確認するために簡単に変更できます。手動モードを使用すると、アプリケーションを実行しているクライアントマシンのハードウェアによってこれまでに課せられたソート/グループ化/フィルタリング/サマリーの制限を基本的に取り除くことができます - 強力な計算バックエンドマシンを使用することは、大規模なデータセットを効率的に処理するための最良の方法であり、高速で応答性の高いUIを提供します。まず、アプリケーションのユーザーと話し、大量のデータが表示されることで意思決定に役立つビューについて調べることができます。これらの情報を見つけたら、XamDataGridは、より多くのデータを表示することに対するユーザーの高まる欲求を満たすのに役立ち、優れたユーザー エクスペリエンスを提供します。