Hi Al, thx! you made my day :-) that did the trick! replacing freemarker 2.3.8 with 2.3.13 speeded up my application by almost 100% It still doesn't come anywhere near my old struts2 application but I guess its a fairly small trade-off when considering what struts2 has to offer.
--- joe On Thu, Jun 26, 2008 at 5:09 PM, Al Sutton <[EMAIL PROTECTED]> wrote: > 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] > >
