[
https://issues.apache.org/jira/browse/WW-3750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13233377#comment-13233377
]
Pelladi Gabor edited comment on WW-3750 at 3/20/12 12:43 PM:
-------------------------------------------------------------
I see.
I wrote in the description: "I think we can assume, that the top-level objects
on the value stack will not change during rendering a single struts2 tag."
It seems that this assumption is false. This code:
{code}
<@s.url id="showConfig" action="showConfig" includeParams="none">
{code}
Modifies the top-level object on the value stack named "showConfig". But with
the caching in place, it is evaluated only once. If this is within a loop, this
can cause regression.
By using the struts2 "a" tag, the variable will not be evaluated as a
freemarker variable, but directly as a value stack variable. It does not use
ScopesHashModel. That is why it works.
We have the following options:
* Cache only the parameters object. Every other variable will not be cached.
This keeps the majority of the performance improvement without affecting
compatibility.
* Keep the current code, and use <@s.a> instead of <a> as you mentioned.
Generally, all occurrences of <@s.url> inside a loop should be reviewed.
For the first option, I am attaching a patch.
The parametersCache field in the patch is made thread-safe using the volatile
keyword, which is enough for this usage.
was (Author: pelladi):
I see.
I wrote in the description: "I think we can assume, that the top-level objects
on the value stack will not change during rendering a single struts2 tag."
It seems that this assumption is false. This code:
{code}
<@s.url id="showConfig" action="showConfig" includeParams="none">
{code}
Modifies the top-level object on the value stack named "showConfig". But with
the caching in place, it is evaluated only once. If this is within a loop, this
can cause regression.
By using the struts2 "a" tag, the variable will not be evaluated as a
freemarker variable, but directly as a value stack variable. It does not use
ScopesHashModel. That is why it works.
We have the following options:
* Cache only the parameters object. Every other variable will not be cached.
This keeps the majority of the performance improvement without affecting
compatibility.
* Keep the current code, and use <@s.a> instead of <a> as you mentioned.
Generally, all occurrences of <@s.url> inside a loop should be reviewed.
For the first option, I am attaching a patch.
> ScopesHashModel calls OgnlValueStack.findValue too many times during
> rendering freemarker templates
> ---------------------------------------------------------------------------------------------------
>
> Key: WW-3750
> URL: https://issues.apache.org/jira/browse/WW-3750
> Project: Struts 2
> Issue Type: Improvement
> Components: Value Stack
> Affects Versions: 2.3.1.1
> Reporter: Pelladi Gabor
> Assignee: Johannes Geppert
> Priority: Minor
> Labels: patch, performance
> Fix For: 2.3.2
>
> Attachments: WW-3750-2.diff, WW-3750-parameters.diff, WW-3750.diff
>
>
> I saw using a profiler, that OgnlValueStack.findValue(String) gets called
> about a thousand times during rendering a page. Most of the calls are coming
> from ScopesHashModel.
> All freemarker templates contain a lot of references to e.g. "parameters".
> This variable is evaluated in ScopesHashModel over and over again, which
> takes about 10% time of total page load.
> I think we can assume, that the top-level objects on the value stack will not
> change during rendering a single struts2 tag. So with a little caching, we
> can eliminate most of the findValue method calls.
> In my application I tested this modification and didn't notice any side
> effects or bugs. The OgnlValueStack.findValue(String) calls on a test page
> went down from a thousand to a hundred. This improved overall page rendering
> time from about 400ms to 360ms.
> Patch is attached.
> Please review it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
