来自 java 的 libxml2

发布于 2024-09-19 03:55:56 字数 1008 浏览 7 评论 0原文

这个问题有点相关 Java 中小型、简单文档的最快 XML 解析器 但还有一些细节。

我正在开发一个需要解析许多(数十百万)小型(大约 300k)xml 文档的应用程序。当前的实现使用 xerces-j,在 1.5 GHz 机器上每个 xml 文档大约需要 2.5 毫秒。我想提高这个性能。我看到这篇文章

http ://www.xml.com/pub/a/2007/05/16/xml-parser-benchmarks-part-2.html

声称 libxml2 的解析速度比任何 java 解析器快一个数量级。我不确定我是否相信,但这引起了我的注意。 有人尝试过从 jvm 使用 libxml2 吗?如果是这样,它比 java dom 解析(xerces)更快吗? 我想我仍然需要我的 java dom 结构,但我猜测从 c 结构的 dom 复制到 java-dom 应该不用多久。我必须有 java-dom - 在这种情况下 sax 不会帮助我。

更新:我刚刚为 libxml2 编写了一个测试,它并不比 xerces 快……尽管我的 C 编码能力非常生疏。

更新我在这里扩大了问题的范围: 为什么 sax 解析比dom解析? stax 是如何运作的? 我对抛弃 dom 的可能性持开放态度。

谢谢

This question is somewhat related to
Fastest XML parser for small, simple documents in Java
but with a few more specifics.

I'm working on an application which needs to parse many (10s of millions), small (approx. 300k) xml documents. The current implementation is using xerces-j and it takes about 2.5 ms per xml document on a 1.5 GHz machine. I'd like to improve this performance. I came across this article

http://www.xml.com/pub/a/2007/05/16/xml-parser-benchmarks-part-2.html

claiming that libxml2 can parse about an order of magnitude faster than any java parsers. I'm not sure if I believe it, but it caught my attention. Has anyone tried using libxml2 from the jvm? If so, is it faster than java dom parsing (xerces)? I'm thinking I'd still need my java dom structure, but I'm guessing that copying from a c-structured dom into java-dom shouldn't take long. I must have java-dom - sax will not help me in this case.

update: I just wrote a test for libxml2 and it wasn't any faster than xerces... granted my c coding ability is extremely rusty.

update I broadened the question a bit here:
why is sax parsing faster than dom parsing ? and how does stax work?
and am open to the possibility of ditching dom.

Thanks

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

怼怹恏 2024-09-26 03:55:57

在 Java 中,StAX JSR-173 通常被认为是最快的解析方法XML。 StAX 有多种实现,Woodstox 实现通常被认为速度很快。

为了提高性能,我会避免使用 DOM。你用 XML 做什么?如果您最终将其作为对象处理,则应该考虑 OXM 解决方案。标准是 JAXB JSR-222。 JAXB 实现,例如 MOXy(我是技术负责人)甚至允许您执行以下操作:可以提高性能的部分映射:

In Java, StAX JSR-173 is generally considered to be the fastest approach to parsing XML. There are multiple implementations of StAX, the Woodstox implementation is generally regarded as being fast.

To improve performance I would avoid DOM. What are you doing with the XML? If you are ultimately dealing with it as objects, the you should consider an OXM solution. The standard is JAXB JSR-222. JAXB implementations such as MOXy (I'm the tech lead) will even allow you to do a partial mapping which will improve performance:

微暖i 2024-09-26 03:55:57

首先,你的问题不包含问题。你想知道什么?

我想您正在使用 JNI 将 c-dom 转换为 java-dom。我不知道是否有官方数字,但根据我的经验,c+JNI 通常比直接在 java 中执行要慢。

如果你真的想加快处理速度,请尝试摆脱 dom(为什么需要它?也许我们可以一起想一个解决方案)。如果所有 xml 文件具有相同的架构,请使用您自己的专用数据模型(和 SAX 解析器)。

如果您只使用 xml 的子集(即没有命名空间,只有很少的属性),请考虑编写自己的解析器来直接生成更高效的 java 对象(但我不建议这样做)。

First of all, your question does not contain a question. What do you want to know?

I suppose you were using JNI to convert the c-dom into a java-dom. I dont know if there are official numbers, but in my experience c+JNI often is slower than directly doing it in java.

If you really want to speed up your processing, try to get rid of the dom (why do you need it? Maybe we can think of a solution together). If all xml files have the same schema, use your own specialized data model (and a SAX parser).

If you only use a subset of xml (i.e. without namespaces, only few attributes), consider writing your own parser that directly produces more efficient java objects (but I would not recommend that).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文