Hi Andreas,
FYI, OGNL is one of the biggest bottlencecks in Tapestry. I'm learning
about it from performance testing my own app, but I could not say it
better than what Patrick explained a while back on this list. His post
was regarding Tap 3.0.3, but from my Tap4 tests, the OGNL performance
is still very much a case for performance tweaks. In short, try to
limit your OGNL usage to what's absolutely necessary, and do the rest
in plain Java. My app is growing large very quickly, but I'm able to
keep OGNL down to simple one-dot expressions.
Perhaps you've seen Patrick's post (it's really well explained), but
I'm including it here:
-------------------------------------------------------------------------
From: Patrick Casey <[EMAIL PROTECTED]> Mailed-By: jakarta.apache.org
Reply-To: Tapestry users <tapestry-user@jakarta.apache.org>
To: Tapestry users <tapestry-user@jakarta.apache.org>
Date: Feb 15, 2006 11:38 AM
Subject: RE: Optimization Questions
The last time I did a serious performance attach on a Tapestry 3.0.3
app, by far the biggest performance bottleneck was the demon OGNL. Howard
and I went round and round on that one, but the upshot is that Howard's
using OGNL right, and OGNL is actually a decent reflection package (and
hence faster than, say, Apache PropUtils), but it's still not native code.
Given that some page renders can require literally thousands of OGNL
calls (I was up at like 1800 distinct evaluations for one page), its often
the bottleneck.
I've pasted my OGNL performance hints below. None of it's rocket
science, but aggressively following these techniques knocked about 50% off
the page render time on my forms, so there's some serious performance to be
gained.
--- Pat
Rules to Make OGNL Run Faster:
**Dot Pruning:
Reduce the number of "dots" in your calls. For example, lets say you had a
call that read: "ognl:foo.bar.dog". That's a three-hopper as far as OGNL is
concerned, requiring three times the work of a one hopper like "ognl:dog".
You can make the thing run 3X as fast if your go into your page class and
create a getter and setter for "dog" e.g.
Public String getDog() {
Foo foo = getFoo();
If (foo == null)
Return null;
Bar bar = getBar();
If (bar == null)
Return null;
Return bar.getDog();
}
Public void setDog(String value) {
Foo foo = getFoo();
If (foo == null)
Return;
Bar bar = getBar();
If (bar == null)
Return;
Bar.setDog(value);
}
What we've done is created two java stub classes that do 2/3 of
the work for OGNL so it only has to make one "hop" to get at the methods it
needs. Net result is it'll run 3X as fast.
**Be Static:
OGNL isn't smart enough to realize that a reference to a public
static final object is, in fact, static. It resolves the whole thing via
inspection each time. So if you want to make an expression that reads, for
example:
<span jwcid="@Insert" value="ognl:@[EMAIL PROTECTED]" />
It's faster to do:
<span jwcid="@Insert" value="Monday" />
You're kind of Sol if you change "Monday" to "Mon" mind you, so
I wouldn't switch over to literals like this until rollout time, but it does
make a difference.
**Avoid Putting Components Inside Foreach:
There's a lot of OGNL grinding going on behind the scenes to support a
foreach, and even more ognl grinding going on to call a component. So if you
put the one inside the other, well, CPU cycles burn. So in many cases:
<span jwcid="@Foreach" source="ognl:listOfDogs" values="ognl:currentDog">
<span jwcid="@DogDisplay" dog="ognl:currentDog"/>
<span>
Is *dramatically* slower than moving the foreach down into the DogDisplay
component e.g.
<span jwcid="@ListOfDogsDisplay" listOfDogs="ognl:listOfDogs" />
And then combing the foreach and the dogdisplay logic inside of one
component. Otherwise every time the sub component gets called there's at
least one ognl set/get pair being executed to push data into the component
and pluck it out again. Basically pretend you're working in a system which
has *really* inefficient method call overhead and view components as
methods. Then optimize to reduce method calls.
**Notes:
If you do your own profiling, one warning I do want to give is that on
JProfiler at least, it can "hide" the true culprit in the bowels of the call
stack. So if you have an ognl expression that reads
"ognl:foo.bar.thisMethodTakesForever", it'll show up as a lot of CPU time
belonging to ognlGet until you dive into the call stack and get to
whatever's at the pointy end of the get. Most of the time the actual get is
trivial so all the time really is going into OGNL, but sometimes if you have
expensive gets (or sets) it can make OGNL look worse than it is.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
