我是一名支持工程师,我们公司的产品允许XSLT转换定制输出.
为此目的我做了一个xsl转换.它适用于典型大小的源文件(几个100k),但偶尔会有一个非常大的(10M)源文件.在这种情况下,即使我让它磨几天也不会产生输出.
SW工程团队对其进行了测试并发现,对于转换和大型源文件确实非常慢(>天),如果我们的产品被编译为使用.Net 1.1中的转换引擎,但是如果他们用.Net编译它2.0,速度快(约1-2分钟).
显而易见的长期解决方案是,等待下一个版本.
从短期来看,我想知道以下几点:1)XSLT是否足够灵活,以便有更高效,效率更低的方法来实现相同的结果?例如,有可能我构造xsl的方式,变换引擎必须多次从源文件的开头迭代,越长越长,因为下一个结果片从开始越走越远?(Schlemiel the Painter),或者2)它是否更依赖于变换引擎如何解释xsl?
如果是2,我不想浪费大量时间来改进xsl(我不是一个很大的xsl天才,我很难实现我所做的一点......).
谢谢!
我不熟悉.NET实现,但是通常可以做一些事情来加速大型文档的处理:
除非绝对必要,否则请避免在Xpath表达式中使用"//".
如果您只需要与Xpath表达式匹配的第一个或唯一元素,请使用"[1]"限定符,例如"// iframe [1]".许多处理器为此实现了优化.
只要有可能,在处理大量XML输入时,看看您是否可以围绕基于流的解析器(如SAX)而不是基于DOM的解析器设计解决方案.