我正在开发一个使用以下技术的项目。 Java、XML、XSL
大量使用 XML。很多时候我需要 - 将一个 XML 文档转换为另一个 - 应用一些业务逻辑后将一个 XML 文档转换为另一个。
一切都将被构建到 EAR 中并部署在应用程序服务器上。由于用户数量巨大，在定义编码标准之前我需要考虑性能。
我不是 XSL 的忠实拥护者，但我想了解在这种情况下使用 XSL 是否是更好的选择，或者我应该只坚持使用 Java。请注意，我只要求将 XML 转换为 XML 格式。我没有将 XML 转换为 HTML 等其他格式的要求。
从性能和可维护性的角度来看 - JAVA 不是比使用 XLST 进行 XML 到 XML 转换更好的选择吗？
【问题讨论】：
标签： java xml performance xslt
根据我以前对此类应用程序的经验，如果您有性能瓶颈，那么它不会是 XSLT 处理。 （唯一的例外可能是处理非常复杂并且程序员对 XSLT 非常缺乏经验。）如果您正在处理大型文档，XML 解析或序列化可能会出现性能瓶颈，但是这些将应用您用于转换的任何技术.
在 XSLT 中编写简单的转换比在 Java 中编写代码要简单得多。复杂的转换通常也更容易在 XSLT 中编码，除非它们大量使用 Java 类库中免费提供的功能（例如日期解析）。当然，这仅适用于同样熟悉两种语言编码的人。
当然，在你开始谈论具体数字之前，除了挥手致意之外，不可能给出更多关于性能的建议。
【讨论】：
我同意上述回复。与在 Java 中执行转换相比，XSLT 的开发速度更快、更简洁。您可以更改 XSLT 而无需重新编译整个应用程序（只需重新创建 EAR 并重新部署）。手动转换应该总是更快，但代码可能比 XSLT 大得多，因为 XPATH 和其他技术允许非常简洁和强大的表达式。尝试几个 XSLT 引擎（提供的 java、saxon、xalan...）并尝试调试和分析 XSLT，使用独立 IDE Altova XMLSpy 等工具来检测瓶颈。尝试加载 XSLT 转换并在处理需要相同转换的多个 XML 时重用它。另一种选择是将 XSLT 编译为 Java 类，允许更快的解析（saxon 似乎允许这样做），但更改并不像重新编译 XSLT 和生成的类那样容易。
我们使用 XSLT 和 XSL-FO 为计费软件生成发票。我们从数据库中提取数据并创建一个 XML 文件，使用 XSL-FO 使用 XSLT 对其进行转换，并使用 Apache FOP 处理结果 XML（FO 指令）以生成 PDF。在生成多页发票时，在多用户环境中并根据用户请求（在线处理）在不到一秒的时间内完成工作。我们还进行批处理（计费周期），并且由于重用 XSLT 转换，这项工作完成得更快。仅对于非常大的 PDF 文档（>100 页），我们会遇到一些麻烦（几分钟），但最昂贵的任务始终是使用 FO 处理 XML 到 PDF，而不是使用 XSLT 处理 XML 到 XML。
如常说的那样，如果您需要更多的处理能力，您可以“添加”更多的处理器并轻松地并行完成工作。如果您有使用 XSLT 的经验，我认为使用 XSLT 节省的时间可以用来购买更多硬件。这是使用强大的开发工具来节省开发时间并购买更多硬件或“手动”执行操作以获得最佳性能的二分法。
像 ESB 这样的集成工具在很大程度上基于 XSLT 转换来将 XML 数据从一个系统（发送方）适应到另一个系统（接收方），并且通常可以在一秒钟内执行数百个“事务”（数据处理和集成）。
【讨论】：
如果您使用现代 XSLT 处理器，例如 Saxon（提供免费版本），您会发现性能非常好。此外，从长远来看，XSL 转换将比硬编码的 Java 类更易于维护。
（我与撒克逊的作者没有任何关系）
【讨论】：
这是我基于经验数据的观察。我广泛使用 xslt，并且在许多情况下作为用 java 实现的数据处理器的替代方案。我们编译的一些数据处理器涉及更多。我们主要通过oxygenxml 编辑器使用SAXON EE。这是我们在转换性能方面注意到的。
对于不太复杂的 xsl 样式表，性能相当好（读取 30MB xml 文件并生成 2s 超过 20 个 html 内容页面，有很多 div 结构）。并且就文件大小的变化而言，性能差异似乎是线性的或更少。
但是，当 xsl 样式表的复杂性发生变化时，性能会发生指数级变化。（同一个文件，在经常调用的模板中引入函数调用，该函数实现简单的 xpath 解析，可以改变处理时间，对于同一个文件，从 2s 到 24s）而且函数的引入和函数调用似乎是罪魁祸首。 也就是说，我们还没有进行详细的性能审查和代码优化。 （仍处于 alpha 模式，性能仍在我们的限制范围内 - 即批处理作业）。我必须承认我们可能“滥用”了 xsl 函数，因为在很多地方我们使用了将代码抽象为函数的想法（除了使用模板）。我的怀疑是，由于调用 xslt 模板的性质，在实现过程中可能会有很多最终递归（对于 xslt 处理器），如果没有优化，函数调用会变得很昂贵。我们认为我们编写 xsl 脚本的“策略”改变（更以 XSLT/XPATH 为中心）可能有助于提高 xlst 处理器的性能。例如，使用 xsl 键。所以是的，我们可能和被指控的处理器一样有罪:)
另一个性能问题是内存利用率。虽然 RAM 在技术上不是问题，但一个简单的处理器从 1GB (!!!) 到 6GB 以进行单次调用/转换并不完全符合犹太教规。可能存在可扩展性和容量问题（取决于应用程序和使用情况）。这可能与底层 xlst 处理器关系不大，而与编辑器工具关系更大。这似乎对实时调试样式表（即单步执行 xslt）产生了巨大影响。
几个观察： - 处理器的命令行或“生产”调用具有更好的性能 - 对于连续运行（调用 xslt 处理器），第一次运行时间最长（比如 10 秒），连续运行时间要少得多（比如 4 秒）。再次，可能与编辑器环境有关。
也就是说，虽然处理器的性能有时可能会很痛苦，并且取决于应用程序的需求，但我认为如果您考虑这里已经提到的其他因素，例如代码维护、易于实现、快速更改，代码库的大小，性能问题可能会得到缓解，或者在比较使用 XSLT 与 Java（或其他）的实现时可以“接受”（如果最终应用程序仍然可以使用性能数字）
...再见！
【讨论】：