レポートの計算はより複雑で、多くの場合、メモリの計算です。レポートツールがサポートできる容量も、重要な技術的指標です。もちろん、同じメモリ空間でより大きなレポート（より多くのセル）に対応でき、同時に多数のレポートをサポートできるように、レポートが占有するメモリはできるだけ少なくなることを願っています。
この記事では、レポートツールの容量と関連するパフォーマンスを比較して、同じメモリ（利用可能なjvm）スペースでより多くのセルをサポートできるユーザーと、同じスケールのレポートの計算パフォーマンスを確認します。まだ3つの製品があります。RunqianReport V2018、FineReport V10.0、smartbi V9で、これらはすべて同じデータベースと同じテーブルを使用しています。
テストケースは最も単純なレポート形式です。詳細については、以下の説明を参照してください。
使用例1：単純な行テーブル
「販売注文詳細テーブル」、48フィールド（レポートに対応する48列）、合計データ量は130,000です。
行レポートは、ページングメソッドと完全なデータセット計算メソッドのみを使用してテストします。テーブルサンプルは次のとおりです。
JVM：1.6G利用可能
試験結果
テストデータに基づくと、Runqianの容量はFansoftの容量よりもはるかに強く、容量が許す場合はパフォーマンスもはるかに優れており、Runqianの計算エンジンがより高度で効率的であることを示しています。
柔らかさの理由は、他のデータからもわかりますが、240万グリッドで計算できますが、バックグラウンドタイムは、ランドライの4倍以上です。480万グリッドまで、バックグラウンドタイムはランドライの7倍に達しています。したがって、グリッドが多いほど、FanRanのバックグラウンド計算が非効率になります。
smartbiの場合、リストレポートはデータソースのページングメカニズムのみを使用でき、レポートに設定されたページ付け行の数に従って取得されます。リストレポートでは、ページあたり最大2000行しか許可されず、完全なデータセットのレポートはサポートされません。この使用例は同じ条件で比較することは不可能です。
また、smartbiページングの状況もテストしました。グリッドが240万個、合計時間が22秒、バックグラウンドが20秒の場合、600万個のグリッド、合計時間が56秒、バックグラウンドが53.5秒です。ランドライデータセットよりもパフォーマンスが低いことがわかります。計算ははるかに遅くなりますが、ページングメカニズムが使用された後はオーバーフローは発生しません。
使用例2：クロス集計
データベース「製品販売テーブル」、テーブルデータを使用して、データセットを含むテストレポート
各注文（合計50注文）には15の異なる製品があり、各製品には対応する販売金額があります。
クロス集計は、ページングと非ページングの2つの形式でテストされます。表のサンプルは次のとおりです。
JVM：1.6Gが利用可能です。
試験結果
非ページレポート
まず、比較のためにデータソースを使用せずにレポートテストを使用します。結果は、限られたスペースに収容できるセルの数を単に確認するだけです。
レポートはページングされていません（または1ページ）：
このうち、バックグラウンドタイムのプラス記号（+）の左側と右側のデータは、それぞれ「レポートの計算時間」と「htmlの生成時間」です。ページングがない場合、FanRuanとsmartbiのバックグラウンドはhtmlを生成するための時間を出力しないため、区別はありません。
注：Runqianのテスト結果から判断すると、1ページのセルの数に関係なく（240万ブラウザはロードできなくなります）、ここではテストされません。計算できても、ブラウザはロードできません。これは意味がありません。
smartbiは数十万のセルしか保持できず、レポートはバックグラウンドでしか計算できませんが、ページをレンダリングできなくなっていることがクロステーブルからわかります（ページはレンダリングされない場合がありますが、5分以上かかります）。 、ページの操作はできません）。
Fan Ruanは、数十万のグリッドを保持できます。Runqianのバックグラウンド計算は通常どおり、240万時間と高速であり、そのパフォーマンスは依然として優れています。
次に、テストするデータセット、小規模（750グリッド、50行* 15列、および750データのみ）クロスレポートを含むレポートを使用します。後で、対応する大規模比較に結果を展開します。
このうち、拡張生産モデルは次のとおりです（30万グリッドへの拡張を例にとります）
つまり、従来のクロスレポートに基づいて、各行（A3）および列（C1）に1つのレイヤーを追加して、水平および垂直を複数回繰り返します。たとえば、行の数は10倍に拡大されて500行になり、列は40倍に拡大されて600列になります。セルの総数300,000まで。
テストデータは次のとおりです。
データセットを使用した場合と使用しない場合のレポートテストデータを比較しても、結論は同じであり、乾式乾燥が最適であり、Fansoftの計算とレンダリングはsmartbiよりも強力です。これにより、レンダリング機能を比較する前回の記事の結論が再度確認されます。
ページ付けされたレポート
レポートのページングと組み合わせる場合は、比較データを確認し、上記のデータセットでレポートを使用してください。Fanruanとsmartbiは、フレーム数が120万に達したときにhtmlまたはページレンダリングを生成しています。ページネーションを使用すると、フロントエンドリクエストに従ってhtmlを生成した後にページがレンダリングされます。ただし、ページが大きくない場合、ページは使用されなくなります。このリンクでオーバーフローが発生しました。これにより、レポート計算プロセス中に容量をテストできます**：**
上記のテスト状況と組み合わせて、ページング時に120万グリッド数（ページあたり100行* 600列、合計20ページ）から直接開始します。Smartbiクロスレポートは、指定された行数によるページングをサポートしていません。ドキュメントを組み合わせてカスタマーサービスに相談した後、「行ページング」+ Excelページ設定を使用して、用紙のズーム率に応じてページあたり約100行のデータページングを実現します。
テスト結果から判断すると、Runganの容量はFanruanやSmartbiの容量よりもはるかに強く、容量が許可されている場合でもパフォーマンスは最適です。さらに、FanRuanは、コンピューティング効率と容量の点でsmartbiよりも優れています。
総括する
一般に、Runqianレポートには、レポートの計算と容量に明らかな利点があります。速度が速く、メモリ使用量が少ないため、Runqianのレポートエンジンがより高度で効率的であり、大規模レポートまたは同時実行数をサポートできることを示しています。Fansoft容量は真ん中にあり、計算速度は遅く、多数のグリッドはサポートできませんが、通常のレポートまたはわずかに大規模なレポート、または同時レポートの数は引き続きサポートできます; smartbiの計算と容量は明らかにはるかに悪いです（テストプロセスはまだです）関数も貧弱であることがわかりますが、それは今回のテストポイントではありません）、少し大きいテーブルまたはより多くの同時実行性は無能になります。