And again ... was this Tapestry 3 or Tapestry 4? On 11/21/05, Patrick Casey <[EMAIL PROTECTED]> wrote: > > A couple of things: > > Compiled expressions make a huge difference; I have a bit of egg on > my face in this regard. 100000 runs of the same compiled ognl expression run > significantly faster than the beanutils (100 or so ms). Unfortunately, that > still doesn't help to explain where the time is being burned in production. > > I definitely am not disabling the cache, but just to be > double-secret sure I ran the profiler again and stuck a breakpoint in the > expression initializer. The expressions get initialized on first page render > and we never stop there again, so we're definitely yanking subsequent page > renders out of the pool. Additionally, I've been profiling renders 2..6 > typically so as not to pollute the profile with the page creation (I'm more > interested in runtime performance). > > I can't seem to find the source code for ognl on open symphony, > otherwise I could dive right in and see what is going on here, but what I > can say is this: > > To render the page 5 times, Tapestry calls > > Ognl.getValue(<parsed expression>, <context>, <root>) 955 times. > These 955 evaluations take a total of 493 ms. > > It also calls > Ognl.setValue(<parsed expression>, <context>, <root>) 1,070 times > These 1,070 evaluations take a total of 540 ms > > So we're looking at about 0.5 ms/OGNL call on my setup. > > Total time (CPU) to render the page (5X), from the time we hit the > Servlet's doGet method is 2,006 ms, meaning we're spending just over half of > the total page render time inside of OGNL. Prior to my ognl dot pruning, it > was more like 3.5 seconds for 5 renders, of which 2.4 second of it was spent > inside of OGNL. > > It's not a Tapestry bug that I can see e.g. you're absolutely right > in that you are compiling the expressions, but even with the compiled > expressions that's still where the time is being burned. > > So all my profiling is telling me the OGNL is the point of attack to > improve tapestry performance. Unfortunately, your pointing out that you're > *already* compiling the expressions, and my sandbox testing to the effect > that compiled ognl expressions, at least compared to the obvious > alternatives, are actually pretty fast, has me scratching my head. > > Because, *if* OGNL isn't inherently slow and, instead, we're running > up against the unalterable wall of the java reflection API, *then* you > byte-code enhancement approach may be the only solution. After my first > round of sandbox testing though, I'd begun to let myself hope there might be > a silver bullet out there. Now, I'm quite a bit less confident. > > --- Pat > > > -----Original Message----- > > From: Howard Lewis Ship [mailto:[EMAIL PROTECTED] > > Sent: Monday, November 21, 2005 3:19 PM > > To: Tapestry users > > Subject: Re: A Bit of Profiling Goodness > > > > Wondering if you could also try OGNL using compiled expressions? That > > may be the problem. Tapestry compiles the expressions with OGNL > > before using them (and caches the compiled expressions). > > > > Also (please forgive me) on your live app, was caching disabled? With > > caching disabled, the OGNL cache will be cleared at the end of each > > request, forcing it to re-introspect as well. > > > <snip> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
-- Howard M. Lewis Ship Independent J2EE / Open-Source Java Consultant Creator, Jakarta Tapestry Creator, Jakarta HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
