解析 EL 值表达式的性能

Question

我有一个 JSF2 应用程序，它呈现一个包含复杂内容的大表。不幸的是，每个请求最多需要 6 秒来处理。在阶段监听器中使用简单的调试输出，我可以看到性能损失均匀分布在处理组件树的所有阶段。所以我启动了一个分析器来详细查看发生了什么，并发现在一个简单的请求中评估了超过 300.000 个 ValueExpressions。

它们解析为没有任何逻辑的非常简单的 getter，因此问题不在于执行这些表达式背后的代码，而是解析表达式字符串并调用 getter 方法。这导致了几个问题:

1.) 有什么办法可以加快方法表达式的解析。也许是隐藏的“启用缓存”标志或其他东西。

2.) 似乎大多数表达式不是在实际需要的渲染响应阶段内计算的，而是在其他阶段计算的。似乎没有必要解析例如 styleClass在渲染阶段以外的任何其他阶段。我可以防止这种情况吗？

3.) 当然，在我的 facelets 页面中最小化 EL 表达式的数量应该有助于获得更高的性能，但似乎我不能真正做到这一点:许多属性(如上面提到的 styleClass 示例)实际上依赖于表行，但只能在列上设置。因此，有 10 列，每个表达式的计算过于频繁。我见过这样的例子，其中 rowClasses表的属性用于有条件地设置行的样式，但由于表是可排序的，如果不滚动我自己的排序机制，这将无法工作。有没有更好的方法来实现这一点？

4.) 一个更简单的问题:有没有办法在组件树中缓存变量(就像 ui:repeat 提供对列表内容的访问并解析表达式以仅获取列表一次，但仅针对一个变量) ?

非常感谢您的所有回答和提示!

编辑:

经过进一步调查，我发现对于每个rendered=#{someExpression} ，仅在渲染响应阶段，表达式每行计算 6 次。我知道 JSF 可能会多次调用我的 getter，但我认为这是因为它们可以在每个阶段内调用。在渲染过程中，这些值不应该改变，所以我想它们可以被缓存。

单步调试调试器中的代码，看起来像javax.faces.component.ComponentStateHelper (出现在导致评估方法调用的每个堆栈跟踪中)提供了一个映射来执行这种缓存。但是，这似乎不像我期望的那样工作，并且总是重新评估表达式......

Answer 1

1.) Is there any way to speed up the resolving of method expressions. Maybe a hidden "enable caching" flag or something.

没有人想到。

2.) It seems most of the expressions are evaluated not inside the render response phase, where they are actually needed, but during the other phases. It seems unnecessary to resolve for example styleClass during any other phase than the render phase. Can I prevent this?

据我所知，这应该不会发生。在渲染响应之前可以/应该解决的唯一问题是 rendered , required , disabled , readonly和 value .

3.) Of course, minimizing the number of EL expressions in my facelets page should help getting more performance, but it seems that I cannot really do this: Many attributes (like the styleClass example mentioned above) are actually dependent on the table row, but can only be set on the column. So, having 10 columns, each expression is evaluated much too often. I've seen examples where the rowClasses attribute of the table is used to conditionally style the rows, but as the table is sortable, that won't work without rolling my own sorting mechanism. Is there a better way to implement this?

您可以将样式工作移交给 JS/CSS 的智能部分/组合。

4.) One more simple question: Is there a way to cache variables in the component tree (just like ui:repeat provides access to the contents of a list and resolves the expression to get the list only once, but just for one variable)?

使用JSTL <c:set> .我不确定这到底会产生什么影响，但是您基本上只是将问题转移到其他地方。一个 #{variableName}在任何范围内定位它仍然会产生成本。您还可以考虑在访问变量时显式命名范围。例如 #{sessionScope.beanname}这应该跳过不必要的页面扫描和请求范围。