On Fri, Jun 27, 2008 at 7:25 AM, yorlick kilroy <[EMAIL PROTECTED]> wrote:
> 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. correction: I meant "old Struts1 application" not Struts2 > > --- 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] >> >> >
