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