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]
