Rickard,
Thanks for sending the test application. I've been using monthlist.jsp while
testing rendered then hand bashed code. After some preliminary bashing :)
I think it will be possible to call all setters (except runtime expressions)
only once per run of the page. Also, we can create / obtain tag handler instances
only once per page run.
Anyway... after tweaking the rendered code, I was disappointed that there
wasn't much of a change in the performance when I hit the page directly.
The "optimized" version was even a bit slower :( So, I hooked it up to a
profiler. It said that most of the time was being spent in
webwork.util.ValueStack.findValue which is called from some of
the setters and some of the do[Start|End]Tag methods. So even though
the setters and tag handler "new"s were optimized, there wasn't much
change in page evaluation time. (A strange note: under the profiler, the
optimized version ran in about 75% of the time it took the un-optimized
version. Not sure why the big difference, but I have seen variations
like that before when code is run under a profiler.)
So, Is there any way you could send me a new webwork.jar (no need for the
whole .war) that has tag implementations optimized for tag instance and
setter call reuse?. If you can move some/many of the calls to ValueStack.findValue
out of the doStart/doEnd methods, that should help.
Yes, I know this doesn't solve the problem of why weblogic was faster
for you, but any tag related optimizations we can make should help other
tag users (me and my day job included).
If you send a new jar, I'll test it out and let you know.
-casey
Rickard Öberg wrote:
>
> [EMAIL PROTECTED] wrote:
> > > Jasper performance is a high priority thing for us (nr 1. on our "system
> > > performance fixing" list actually), so if possible, absolutely. I can't
> > > say I've delved that far into Jasper yet though. It was a bit hard to
> > > read.
> >
> > I'm working on a refactoring of jasper, and "easy to read" is a big
> > priority. It's moving a bit slower than I expected - now I'm back on
> > planning stage after hearing so much bad things about using XSLT :-) But I
> > think there are ways to make ( almost ) everyone happy.
> >
> > I hope in few weeks ( after JavaOne ) we'll have something that works for
> > both 1.1 and 1.2 ( the first part of refactoring ), and we can start the
> > fun part - optimizing it.
>
> Sounds like a good plan :-) I'd be happy to help out with commenting on
> the code. Code contribution is tricky right now (lots of other
> OpenSource projects to manage :-).
>
> > The main problem is to avoid one synchronized call for each tag (
> > "new" _is_also_ a synchronized call on most VMs - it synchronizes
> > the heap !!! ).
>
> Whoa.. I didn't know that.. that's an important factor to consider then.
>
> > Tomcat3.3 has one synchronized call to get the worker
> > thread from the pool - and that doesn't seem to show up in any
> > performance tests.
>
> As long as the synchs are few, and the block itself is short, you should
> be ok.
>
> > We could keep a pool of pools ( probably for each context ). The local
> > pools can be unsynchronized - so we'll have only one sync per page. Each
> > context will have a set of pools ( with the size == the largest number of
> > concurent requests for that context ). And we can of course be agressive
> > in shrinking the pools that were not used recently.
>
> That could work.
>
> > We can try to do some of this in 3.3 space - or in a branch of 3.3 (
> > jasper34 is going to take a while, and I have a feeling you need results
> > fast ).
>
> The big date for me is 2002-01-01. Before that I need some kind of
> "assurance" that it'll improve greatly 'till that time, or we need to
> look at alternatives (*shiver*).
>
> So sooner than later, sure, but preferably righter than sooner. Get this
> stuff right, and I think you'll get lots of new supporters and keep old
> ones ;-)
>
> > Regarding your application - I think we know the problem. There are few
> > things you can do to reduce the memory use, and you could cache and
> > recycle intermediary objects in each tag instance - you could benefit a
> > lot from the reuse of the tags.
>
> I will start looking at optimizations on my side of things to, for sure.
> My code isn't extremely optimized, I know that, but OTOH I've tested the
> same code with WebLogic 5.0 (just to test) and it was waaaay faster, so
> there's definitely room on the JSP side to improve things.
>
> > The memory savings of the thread pooling are not helping your application
> > yet ( since they are very small compared with the rest ), yet you pay the
> > synchronization price ( a lot - since you make heavy use of tags ). With
> > few changes in your app and few changes in the tag pool we could reverse
> > the situation - but if you disable the pool there's little chance you
> > could increase the performance above the current level.
>
> Yup, that seems reasonable.
>
> You mentioned in your private email that there was a lot of
> MethodDescriptor's being created. Please look into where these are
> coming from. They could be associated with the tag setters. Pool/cache
> these and you'll probably see some immediate results.
>
> /Rickard
>
> --
> Rickard Öberg
> Software Development Specialist
> xlurc - Xpedio Linköping Ubiquitous Research Center
> Author of "Mastering RMI"
> Email: [EMAIL PROTECTED]
