当前位置:  开发笔记 > 编程语言 > 正文

什么是最高效的基于Java的流式XSLT处理器?

如何解决《什么是最高效的基于Java的流式XSLT处理器?》经验,为你挑选了2个好方法。

我有一个非常大的XML文件,我需要将其转换为另一个XML文件,我想用XSLT来做这件事.我对内存优化更感兴趣,而不是速度优化(尽管速度也会很好!).

您会为此任务推荐哪种基于Java的XSLT处理器?

你会推荐其他任何方式(非XSLT?,非Java?),如果是这样,为什么?

问题中的XML文件非常大,但不是很深 - 有数百万行(元素),但只有大约3个级别.



1> Dimitre Nova..:

目前只有三种已知的XSLT 2.0处理器,Saxon 9.x在速度和内存利用率方面可能是效率最高的(至少根据我的经验).Saxon-SA(撒克逊的模式感知版本,不作为B(基本)版本免费)具有流式处理的特殊扩展.

从各种现有的 XSLT 1.0处理器,.NET XslCompiledTransform(基于C#,而不是Java!)似乎是冠军.

在基于Java的XSLT 1.0处理器世界中, Saxon 6.x再次非常出色.

更新:

现在,从最初回答这个问题之日起超过3年,没有任何证据表明所提到的XSLT处理器之间的效率差异已经改变.

至于流媒体:

    即使没有任何流式传输,也可以处理具有"数百万个节点"的XML文档.我进行了一项实验,其中Saxom 9.1.07处理了一个XML文档,该文档包含大约一百万个具有整数值的3级元素.转换只是计算它们的总和.在我的计算机上进行转换的总时间不到1.5秒.用过的内存是500MB - 这是个人电脑10年前就可以拥有的东西,

以下是Saxon的信息性消息,显示有关转换的详细信息:

Saxon 9.1.0.7J from Saxonica
Java version 1.6.0_17
Stylesheet compilation time: 190 milliseconds
Processing file:/C:\temp\delete\MRowst.xml
Building tree for file:/C:\temp\delete\MRowst.xml using class net.sf.saxon.tinytree.TinyBuilder
Tree built in 1053 milliseconds
Tree size: 3075004 nodes, 1800000 characters, 0 attributes
Loading net.sf.saxon.event.MessageEmitter
Execution time: 1448 milliseconds
Memory used: 506661648
NamePool contents: 14 entries in 14 chains. 6 prefixes, 6 URIs

    Saxon 9.4有一个saxon:stream()扩展函数,可用于处理大型XML文档.

以下是文档的摘录:

在Saxon中基本上有两种流媒体方式:

突发模式流:使用这种方法,大文件的转换被分解为一小部分文件的转换.依次从输入中读取每个片段,将其转换为内存中的小树,转换并写入输出文件.

这种方法适用于结构相当扁平的文件,例如包含数百万条日志记录的日志文件,其中每个日志记录的处理与之前的记录无关.

此技术的一种变体使用新的XSLT 3.0 xsl:iterate指令迭代记录,代替xsl:for-each.这允许在处理记录时维护工作数据:例如,这使得可以在运行结束时输出总计或平均值,或者使一个记录的处理依赖于文件中之前的记录. .xsl:iterate指令还允许提前退出循环,这使得转换可以从大文件的开头处理数据而无需实际读取整个文件.

XSLT和XQuery都提供了突发模式流,但XQuery中没有与xsl:iterate结构相同的流.

流模板:这种方法遵循传统的XSLT处理模式,即通过将模板规则匹配到每个级别的节点来执行输入XML层次结构的递归下降,但是一次只执行一个元素,而不在内存中构建树.

每个模板都属于一种模式(可能是默认的,未命名的模式),而streaming是可以使用新的xsl:mode声明指定的模式的属性.如果模式被声明为可流式传输,则该模式中的每个模板规则都必须遵守可流式处理的规则.

流处理中允许的规则非常复杂,但基本原则是给定节点的模板规则只能按顺序读取该节点的后代一次.当前Saxon实现中的限制还有其他规则:例如,虽然分组使用在理论上与流实现一致,但目前尚未在Saxon中实现.

    XSLT 3.0将具有标准流功能.但是,W3C文档仍处于"工作草案"状态,并且流式规范可能会在后续草稿版本中发生变化.因此,不存在当前草案(流)规范的实现.

    警告:并非所有转换都可以在流模式下执行 - 无论XSLT处理器如何.对于大型文档而言,不可能以流模式(具有有限的RAM量)执行的转换的一个示例是对它们的元素进行排序(例如,通过共同属性).


这是一年之后,Dimitre的评论仍然存在.事实上,撒克逊人的速度越来越快.

2> Stephen Denn..:

您可以考虑STX,其Java实现是Joost.由于它类似于XSLT,但作为流处理器,它能够使用非常少的RAM处理大量文件.

Joost可以用作标准的javax.xml.transform.TransformerFactory

推荐阅读
女女的家_747
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有