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] > >
