Notice the hat has a little propeller or "prop"? > this may be _slightly_ off topic, but can i just ask what exactly does > putting a hat on the tapestry logo represent? a swirly hat? the penknife > with the logo, fair enough... represents tools etc.. but a hat on the > logo? > WHY IS THERE A HAT ON IT?!?! im finding it hard to work while i dont know > the answer to this... > > > > On 3/26/06, Adam Zimowski <[EMAIL PROTECTED]> wrote: >> >> Just tried Tapestry-Prop and works painlessly with my Tap4 app. Whatta >> way to go. And since I already took aggresive approach to keep OGNL >> simple, this certainly will eliminate a good half of my OGNL calls. >> >> Adam >> >> On 3/26/06, Adam Zimowski <[EMAIL PROTECTED]> wrote: >> > How nice. Learning something new everyday. This looks like an obvious >> > must-have for any serious Tapestry app. >> > >> > Thanks Ryan! >> > >> > On 3/26/06, Ryan Holmes <[EMAIL PROTECTED]> wrote: >> > > Don't forget about the Tapestry-Prop library at >> > > http://howardlewisship.com/tapestry-javaforge/tapestry-prop/ >> > > Combined with the "dot-pruning" technique this will let you >> eliminate >> a >> > > lot of OGNL. >> > > >> > > -Ryan >> > > >> > > Vincent wrote: >> > > > Hi , >> > > > >> > > > That may explain a lot why the performance of the my application >> slow >> > > > down a lot recently. >> > > > But anyway , is there any plan to improve the performance of OGNL >> , >> > > > since Tapestry 4.0 already released? >> > > > >> > > > On 3/26/06, Adam Zimowski <[EMAIL PROTECTED]> wrote: >> > > > >> > > >> 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] >> > > >> >> > > >> >> > > >> >> > > >> > > --------------------------------------------------------------------- >> > > 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] >> >> >
James Carman, President Carman Consulting, Inc. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
