XSLT 性能考虑

Question

我正在开发一个项目，使用以下技术。 Java，XML，XSLs

大量使用XML。经常需要: -将一个XML文档转换为另一个 -在应用一些业务逻辑后将一个XML文档转换为另一个。

所有内容都将构建成EAR并部署在应用服务器上。由于用户数量庞大，在定义编程标准之前我需要考虑性能问题。

我不是XSLs的铁杆粉丝，但我试图了解在这种情况下是否使用XSLs比仅使用Java更好。请注意，我有将XML转换为XML格式的要求，而不是像HTML等其他格式。

从性能和可维护性的角度来看，难道JAVA不是比使用XLST进行XML到XML转换更好的选择吗？

- user825258

---

只是为了澄清一下...你所说的 XLST 是指类似于大多数 Linux 系统上的 xsltproc 这样的命令行工具吗？ - Chris

Answer 1

根据我之前处理这种应用程序的经验，如果你遇到性能瓶颈，那么这不会是XSLT处理引起的问题。（唯一的例外可能是处理非常复杂且程序员对XSLT非常不熟悉。）如果你正在处理大型文档，则XML解析或序列化可能会存在性能瓶颈，但无论使用什么技术进行转换，都会存在这些问题。

简单的转换在XSLT中编写比在Java中简单得多。除非需要充分利用Java类库中可用的免费功能（例如日期解析），否则复杂的转换通常也更容易在XSLT中编写。当然，这只适用于同样熟练于两种语言编码的人。

当然，在谈论具体数字之前，关于性能问题只能给出笼统的建议。

- Michael Kay

Answer 2

我同意上述回答。与Java中执行变换相比，XSLT开发速度更快，代码更简洁。您可以更改XSLT而无需重新编译整个应用程序（只需重新创建EAR并重新部署）。手动转换应该始终更快，但由于XPath和其他技术允许非常紧凑和强大的表达式，代码可能比XSLT大得多。尝试几个XSLT引擎（Java提供的、Saxon、Xalan等），并尝试使用像独立IDE Altova XMLSpy这样的工具调试和分析XSLT，以检测瓶颈。尝试加载XSLT转换并在处理需要相同转换的几个XML时重用它。另一个选项是将XSLT编译为Java类，从而允许更快的解析（saxon似乎允许），但更改不像您需要重新编译XSLT和生成的类那样容易。

我们使用XSLT和XSL-FO为计费软件生成发票。我们从数据库中提取数据并创建一个XML文件，使用XSLT和XSL-FO进行转换，并处理结果XML（FO指令）以使用Apache FOP生成PDF。当生成多页发票时，在多用户环境中和基于用户请求的情况下，作业在不到一秒钟的时间内完成。我们还进行批量处理（计费周期）并且可以重用XSLT转换，这样作业完成得更快。只有对于非常大的PDF文档（>100页），我们会遇到一些问题（需要几分钟），但最昂贵的任务始终是使用FO将XML处理为PDF，而不是使用XSLT将XML处理为XML。

像ESB这样的集成工具严重依赖于XSLT变换，以使XML数据从一个系统（发送方）适应另一个系统（接收方），并且通常可以在一秒钟内执行数百个“事务”（数据处理和集成）。

- David Oliván

Answer 3

如果你使用现代的XSLT处理器，例如Saxon（有免费版本），你会发现性能非常不错。此外，从长远来看，XSL转换比硬编码的Java类更加易于维护。

（我与Saxon的作者无关）

- Jim Garrison

Answer 4

这是基于实证数据的观察。我广泛使用XSLT，并在许多情况下将其作为Java中实现的数据处理器的替代品。我们编译的一些数据处理器比较复杂。我们主要使用SAXON EE，通过oxygenxml编辑器。以下是我们在转换性能方面注意到的情况。

对于较简单的XSL样式表，性能非常好（读取30MB XML文件并生成20个以上的HTML内容页面需要2秒钟，其中包含许多div结构）。性能的差异似乎与文件大小的变化呈线性或更小的关系。

然而，当xsl样式表的复杂性发生变化时，性能的变化可能是指数级的。（同一个文件，在模板中引入一个经常被调用的函数，并实现一个简单的xpath解析的函数，可以将处理时间从2秒变为24秒）。似乎函数和函数调用的引入是主要罪魁祸首。话虽如此，我们还没有进行详细的性能审查和代码优化（仍处于alpha模式，性能仍在我们的限制范围内-即批处理作业）。我必须承认，我们可能“滥用”了xsl函数，在很多地方我们都使用了代码抽象成函数的思想（除了使用模板外）。我的怀疑是，由于xslt模板的调用方式，实现过程中可能会有很多递归，如果函数调用没有得到优化，它们可能会变得很昂贵。我们认为，在编写xsl脚本的方式上进行“策略”上的改变（更加XSLT/XPATH中心化）可能有助于提高xlst处理器的性能。例如，使用xsl键。所以，是的，我们可能与被指控的处理器一样有罪 :)

另一个性能问题是内存利用。虽然RAM在技术上不是问题，但单个调用/转换的处理器从1GB（！）到6GB并不完全合规。这可能涉及可伸缩性和容量问题（取决于应用程序和使用情况）。这可能与底层xlst处理器无关，更多地与编辑工具有关。这似乎对实时调试样式表（即通过xslt进行步进）产生了巨大影响。

几点观察： - 命令行或“生产”调用处理器具有更好的性能 - 对于连续运行（调用xslt处理器），第一次运行需要最长时间（例如10秒），而后续运行则需要更少的时间（例如4秒）。同样，可能与编辑环境有关。

话虽如此，虽然处理器的性能有时可能会很痛苦，并且取决于应用程序的要求，但我认为如果您考虑到这里已经提到的其他因素，例如代码维护、实现的便利性、快速更改、代码库的大小，那么性能问题可能会得到缓解，或者在使用XSLT与Java（或其他语言）进行实现时，可以“接受”（如果最终应用程序仍然可以满足性能要求）。

...再见！

- young chisango