我这个需要极限的性能，怎么优化都不为过。类似杀软对office文档的检测。

我估计小文件用libhpxml这种需要全部加载到内存、不需要复制字符串而是尽量返回string_view的库。
libhpxml这个自己搞了一个类似string_view的，毕竟这库写出来的那会儿std里还没string_view这个东西。

然后大文件或者无法返回string_view的（xml文件逐块读进来时view可能失效，没失效的话还是可以返回string_view），可以考虑用libxml2的text reader接口。
测试了一下它的性能，xlsx大约10万行、每行3列，对应的xml解开后是20MB，大概需要600多毫秒解析（回调函数为空、啥也不干的情况下）。
这个库的每个节点的name和value都是动态分配内存的，回调函数中如果加上对name和value的操作，多耗时200多毫秒，这多出来的时间基本都是在分配、释放内存。
另外，我发现这个库的文件接口每次默认是读取4KB，比一次性读取整个文件到内存然后用其内存接口要慢一点。

Incredible C++ XML Parser这个库看着也不错，就是要给作者发邮件才能拿到，关键其license是Aladdin Free Public License(AFPL)。

CMarkup我记得代码头部写着是要作者的written permission才能商用。

还有个人居然用纯汇编写的asmxml，惜乎只支持32-bit，不能用于x64。有bug估计也不好维护。

先搞一个比较快的顶着，感觉最后应该是有空时要自己搞一个支持分块读取xml文件，同时又尽量不复制字符串的parser。

顺带说一下，测性能时发现win11的windows defender首次扫描一个9MB的docx大约要500毫秒左右。
随便弄个exe读取docx到内存时，它都会检查，然后缓存检查结果直到重启，保证只扫一次。

【 在 DoorWay 的大作中提到: 】
: 解决了没，用了哪个，libxml2，还是cmarkup
--
修改:z16166 FROM 222.129.205.*
FROM 222.129.205.*

file mapping加上手写sax,比较宽松的xml合法性检查，假设utf8编码，遍历单个700MB的文件，两秒左右完成。升级下硬件，代码再优化一下，应该还能更快。
工作需要自己写的，不能开源。仅供对比一下性能。
【 在 z16166 的大作中提到: 】
: 我这个需要极限的性能，怎么优化都不为过。类似杀软对office文档的检测。
: 我估计小文件用libhpxml这种需要全部加载到内存、不需要复制字符串而是尽量返回string_view的库。
: libhpxml这个自己搞了一个类似string_view的，毕竟这库写出来的那会儿std里还没string_view这个东西。
: ...................
--
FROM 183.42.37.*

思前想后，觉得还是JSON靠谱，巨大的数组可以分成单行，逐行读入，逐行解析。
任意分组打包传输。
【 在 z16166 的大作中提到: 】
: 需要解析docx里的XML里的文本，也就是提取OOXML里的文本。
: 目前采用DOM方式，存在的问题：
: 1、内存占用问题：DOM需要load整个文件进内存，超大文件不能处理。
: ...................
--
修改:ylh0315 FROM 221.221.48.*
FROM 221.221.48.*

docj  java包啊
【 在 z16166 的大作中提到: 】
: 需要解析docx里的XML里的文本，也就是提取OOXML里的文本。
: 目前采用DOM方式，存在的问题：
: 1、内存占用问题：DOM需要load整个文件进内存，超大文件不能处理。
: ...................
--
FROM 112.65.86.*