报表上的计算比较复杂，常常是内存计算，报表工具能支持的容量也就是个重要的技术指标。我们当然希望报表占用的内存尽量少，这样同样内存空间可以容纳更大的报表（更多的单元格），也能支持更大的并发数量。
本文将对比报表工具的容量及相关性能，看同样的内存（可用 jvm）空间下，谁能支持更多的单元格数，以及同样规模报表的计算性能。产品还是三款：润乾报表 V2018、FineReport V10.0、smartbi V9，涉及报表数据来源的均为同库同表。
测试的用例都是最简单的报表格式，具体可参考下面的说明。
“销售订单明细表”，字段 48 个（对应到报表为 48 列），总数据量 13 万条。
行式报表仅采用分页方式且全数据集计算方式测试，表样如下
JVM：可用 1.6G
结合测试数据来看，润乾的容量要比帆软强很多，在容量许可时，性能也要好很多，说明润乾的计算引擎更为精巧高效。
帆软较差的原因从其他数据可以找出，240 万个格数时，都可以算出来，但后台用时是润乾的 4 倍多。到 480 万个格数，后台用时已达润乾 7 倍。所以，格数越多，帆软后台计算也越来越低效。
对于 smartbi，其清单报表只能走数据源分页机制，每次按照报表设定的分页行数来取，且清单类报表每页最大只允许 2000 行，不支持全数据集的报表，该用例就无法做同等条件下的对比了。
我们也测试了 smartbi 分页下的情况： 240 万个格数时，总用时 22s，后台 20s；600 万格数，总用时 56s，后台 53.5s；可以看出来性能较差，比润乾全数据集计算还要慢很多，只是采用分页机制后也不会发生溢出了。
带数据集的测试报表，采用数据库“产品销售表”，表数据
每个订单（共 50 个订单）均有 15 种不同产品，每种产品有对应销售金额。
交叉表采用分页和不分页两种形式测试，表样如下：
JVM：可用 1.6G。
首先，用没有数据源的报表测试来做对比，该结果单纯看有限空间内能容纳多少个单元格数。
报表不分页（或一页）情况：
其中，后台时间内加号（+）左右两边数据分别为“报表计算用时”和“生成 html 用时”。不分页时，帆软和 smartbi 后台不再输出生成 html 用时，所以没有区分。
注：从润乾的测试结果看，单页再多的单元格（240 万浏览器已无法加载）这里就不测了，即便能算出来但浏览器无法加载，没啥意义。
从交叉表可以看出，smartbi 只能容纳小几十万的单元格数，再多的情况仅看到后台算完报表，但页面已经无法渲染（偶尔能渲染出，但时间要 5 分多钟，且页面无法操作）。
帆软可容纳大几十万格数，百万左右就不行了。而润乾在 240 万时后台计算依然正常且速度很快，表现依然优秀。
然后，用带有数据集的报表测试，一个小规模（750 格数，50 行 *15 列，数据只有 750 条）的交叉报表，后面我们把结果扩大到相应大的规模对比。
其中，扩大规模的制作模型如下（以扩大到 30 万格数为例）
即，在常规交叉报表基础上，行（A3）列（C1）各加一层，使横纵向重复多遍，如上行数扩大 10 倍至 500 行，列扩大 40 倍到 600 列，总格数达 30 万个。
测试数据如下：
对比有和没有数据集的报表测试数据，结论也是一致的，润乾最好，帆软计算和渲染强于 smartbi，也再次印证了前面文章对比渲染能力的结论。
再结合报表分页时，看下对比数据，采用上面带数据集的报表。帆软和 smartbi 到 120 万格数时倒在生成 html 或页面渲染环节的，如果分页的话，则会根据前端请求，分页生成 html 后页面渲染，而一般的页都不大，就不会再在这个环节发生溢出。这样可以测试出报表计算过程中的容量 **：**
结合上面测试情况，分页时我们直接从 120 万格数（每页 100 行 *600 列，共 20 页）测起。smartbi 交叉报表不支持指定行数分页，结合文档及咨询客服后采用“行分页”+excel 页面设置中根据纸张缩放比例实现大概每页 100 行数据分页。
从测试结果上看，润乾的容量仍然是比帆软和 smartbi 都要强很多，在容量许可时，性能还是最优。另外，帆软在计算效率和容量两项上均优于 smartbi。
总的来看，润乾报表在报表计算和容量上也占有明显的优势，速度快且占用内存小，说明润乾的报表引擎更为精巧高效，能够支持大规模的报表或并发数量；帆软能力居中，计算速度要慢一些且较大规模格数无法支持，但常规或稍大规模的报表或并发数量都还可以撑得住；smartbi 在计算和容量方面都明显差很多（测试过程中还会发现功能也差，但不是本次测试点），稍大的表格或较多的并发时就会难以胜任了。
