If your benchmark uses multiple threads throw in a freemarker upgrade to
2.3.13 and have another spin :).
One thing you might want to bear in mind is that if you're using a
persistance framework there maybe some back end fetching taking place
between a.b.c and a.b.c.d. Even though you write simple beans and
accessors you can't guarentee whats happening to your objects under the
covers.
Al.
yorlick kilroy wrote:
I replaced OGNL 2.6.11 with the latest 2.7.2 Version.
I did a bit of benchmarking comparing the two and it absolutely surprised
me, that 2.7.2 in some cases is almost twice as slow as 2.6.11
The test scenario:
iterate a large java.util.List in a jsp. the List contains a pretty large
tree of objects. in the jsp I access a String property in the last node of
this object graph. OGNL 2.6.11 takes roughly 600 ms to complete, 2.7.2
roughly 1050 ms
From that I gather that OGNL wasn't designed for high performance when
processing large and complex object trees in jsps. I guess I'll have to go
back and do it like in the old Struts1 days: use shallow objects like in
ActionForms
On Wed, Jun 25, 2008 at 8:31 PM, Dale Newfield <[EMAIL PROTECTED]> wrote:
yorlick kilroy wrote:
Still... the "problem" seems to be the OGNL implementation in struts2.
I'm guessing here, but maybe your issues are related to:
http://jira.opensymphony.com/browse/OGNL-141
Which has been pushed off in Xwork to 2.5:
http://jira.opensymphony.com/browse/XW-631
And which has been pushed off in Struts2 until at least 2.1.3:
https://issues.apache.org/struts/browse/WW-2128
You're welcome to update the version of ognl you're using in your own app
(but remember to add javassist if so).
<s:iterate ... >
<s:property value="#object.a.b.c.name"/>
<s:property value="#object.a.b.c.phone"/>
</s:iterate>
Theoretically this translates to a straight lookup for #object, then
getA().getB().getC().getName()...
If A, B, and C are just accessors, it should be fast. If they do much work
to determine what to return, you're doing that work 2*N times (where N is
the number of times through the loop) instead of just once...why would you
put a long lookup like that in an iterator if it doesn't change with each
iteration?
-Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
