.NET导出Excel的四种方法及评测( 四 ) _.NET

{ sheet.Cells[i + 1, j].Value = https://www.isolves.com/it/cxkf/yy/net/2019-09-02/props[j].GetValue(data[i]); } } excel.Save(path);}注意，Aspose.Cells像Excel软件一样，提供了Sheet1/Sheet2/Sheet3三个默认的工作表，因此取这三个工作表时，不要创建，而是取出来。
性能测试结果如下：
次数分配内存内存提高耗时1404,004,9443,619,52033162357,931,6486,04820783357,934,7447,21620074357,933,3766,28020175357,933,3606,4242007 Aspose.Cells首次占用内存385MB，用于3.3秒，后面每次降低为内存341MB，用时2.0秒。

总结四种导出Excel库的横向评测数据如下，数据取5次数值的内存消耗中位数
，百分比以EPPlus的测试数据为100%基准：
次数分配内存内存占比耗时耗时占比基准(仅反射)9,853,9361.85%1334.82%NPOI1,589,237,064297.83%10355375.32%EPPlus533,598,440100%2759100%OpenXML555,985,936104.19%3884140.78%Aspose357,933,36067%200772.74% 可以得出以下结论：

Demo基于反射，但反射总损耗的性能不高，内存、耗时均不超过5%；
NPOI的性能表现是所有项目中最差的，每次需要分配1.5GB的内存和超过10秒的耗时；
EPPlus表现不错，内存和耗时在开源组中表现最佳；
收费的Aspose.Cells表现最佳，内存占用最低，用时也最短；
较为底层的OpenXML表现非常一般，比EPPlus要差，更不能与收费的Aspose相提并论；

我的感想在真的愿意尝试一下之前，人们很容易相信自己的直觉。底层库，通常能带来更大的可扩展性，能做出上层库很难做的事来。底层库有时性能会更快，就像更底层的C/C++比上层的JavaScript更快一样。但事情也不都如此，如

更高层的React.js能在性能上将较底层的DOM操作比下去
数据库基于集合的操作也比基于游标的操作要快得多

在导出Excel这个例子中，我了解到Excel的xlsx格式是非常复杂的、多个xml的集合。如果基于xml做抽象——也是很正常的做法，拼出6万/10列的数据，需要至少60万个xml标签做拼接，很显然这需要分配/浪费大量内存，因此性能上不来。
我基于以下几点无责任猜测：Aspose内部可能没xml做抽象，而是纯数据做抽象（就像React.js那样），然后再统一写入到Excel文件。因此性能可以达到其它库达不到的目标：

Aspose.Cells对xml等实现相关技术只字未提（可能因为要支持多种文件格式）；
Aspose.Cells是先在内存中创建，再写入文件/流（NPOI也是）；
Aspose.Cells创建Excel时要求客户直接使用Workbook类（NPOI也是）；
Aspose.Cells完全隐藏了Excel的位置（如B3）信息，下标从0开始（NPOI也是）

比较这几点，NPOI也与Aspose.Cells有几分相似，但导出不到6MB的`Excel`它内存分配居然高达1.5GB，是后者的444%！毕竟迭代更新了这么多年了，代码质量我相信应该没问题。因此我再次无责任推测：这可能因为它是从Java那边移植过来的。

我的选择/推荐在我做这个性能评测前，我一直使用的是EPPlus，因为我不喜欢NPOI有第三方依赖，也不喜欢NPOI那些“XSSF”之类的前缀命名，也显然不会去费心思写那么多费力不讨好的OpenXML代码。
更别提这次评测发现EPPlus的性能确实不错，唯一的缺点就是它单元格下标从1开始的设计。即便如此，我还是首选推荐EPPlus 。
近期也经常使用Aspose.Cells这种商业库，它的功能强大，API清晰好用，这个评测也证明它的性能卓越。除了高昂(https://purchase.aspose.com/pricing/cells/net)的价格，没别的缺点了。乃有钱客户/老板的不二之选！
出处：本文转载于微信公众号【DotNet骚操作】，作者【周杰DotNet 】
出处：微信公众号【DotNet骚操作】
微信不能留言，请点击原文链接去博客园留言。
原文链接：https://www.cnblogs.com/sdflysha/p/20190824-dotnet-excel-compare.html