Re: tag pooling question

[Kin-Man Chung]

What you said about using simple pages and comparing their performance
with their servlet equivalents makes a lot of sense and it's obvious that
that needs to be done in any optimization work.

However, real life applications benchmarks are also useful for other
purposes.  They can be used for measuring the overall effectiveness of
optimizations: how effective the individual optimizations are, and how
they interact with each other.  It also would let us find out what
optimizations are important in practice, not just in small test cases.
I'd use these benchmarks for measuring the progress on optimization works,
and as an early warning that certain optimizations are not useful or
even harmful.

- Kin-man

> Date: Wed, 27 Mar 2002 14:54:10 -0800 (PST)
> From: [EMAIL PROTECTED]
> Subject: Re: tag pooling question
> X-X-Sender: <[EMAIL PROTECTED]>
> To: Tomcat Developers List <[EMAIL PROTECTED]>, Kin-Man Chung 
<[EMAIL PROTECTED]>
> MIME-version: 1.0
> X-Authentication-warning: dyn-181.sfo.covalent.net: costinm owned process 
doing -bs
> 
> On Wed, 27 Mar 2002, Kin-Man Chung wrote:
> 
> > Pulling codes out of iteration tag bodies is very high on my list of
> > optimizations that I wnat to do.  I don't think we can do much about
> > general scriplets that contain loops, though.
> > 
> > But before we start on jasper optimization work, we'll need benchmarks
> > and performance analysers.  I have learnt from experience that performance
> > improvement often comes from surprising places, and that optimizations
> > done at the wrong time and place often do more harm than good.  Benchmarks
> > would give us some real metric for us to measure our optimization work,
> > and analyzing tools would let us identify hot spots that need to be 
improved.
> > 
> > I'd appreciate comments, suggestions, and pointers on these two subjects.
> > I'd also appreciate if anyone can donate some real life applications that
> > I can use for benchmarking jasper performance.
> 
> The most usefull tools are OptimizeIt and ab. 
> 
> Simple pages would help much better then complex pages - first find
> out what's the overhead of executin a simple JSP page, with no tags,
> compare it with the equivalent servlet ( HelloWorld ), and find out
> what's wrong. 
> 
> Then use a simple hello world Tag, compare it with the equivalent 
> servlet ( or JSP not using tags ), and find what's wrong.
> 
> Same for a simple iteration tag, compared with a scriptlet
> 
> If you solve those simple problems, and get the tag version 
> in a reasonable limit, I think we'll all be very happy  ( 30% slower 
> would be acceptable for me, even 1/2 the speed of the equivalent 
> scriptlet ).
> 
> Going after 'real life applications' when the simple hello world tag,
> or a simple empty jsp page has a clear performance penalty would be a 
> waste of time.
> 
> ( all that with a reasonable load - I sugest 80 concurent requests )
> 
> Costin
> 


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: tag pooling question

[peter lin]

I'm actually performing a series of benchmarks that are close to what
you describe, though the pages are complex, in that JSTL is used to
markup logic. the test pages are highly dynamic and use includes
extensively to break pieces into logical chunks.

once I am done I will post the results.

peter lin


[EMAIL PROTECTED] wrote:

> The most usefull tools are OptimizeIt and ab.
> 
> Simple pages would help much better then complex pages - first find
> out what's the overhead of executin a simple JSP page, with no tags,
> compare it with the equivalent servlet ( HelloWorld ), and find out
> what's wrong.
> 
> Then use a simple hello world Tag, compare it with the equivalent
> servlet ( or JSP not using tags ), and find what's wrong.
> 
> Same for a simple iteration tag, compared with a scriptlet
> 
> If you solve those simple problems, and get the tag version
> in a reasonable limit, I think we'll all be very happy  ( 30% slower
> would be acceptable for me, even 1/2 the speed of the equivalent
> scriptlet ).
> 
> Going after 'real life applications' when the simple hello world tag,
> or a simple empty jsp page has a clear performance penalty would be a
> waste of time.
> 
> ( all that with a reasonable load - I sugest 80 concurent requests )
> 
> Costin
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: tag pooling question

[Ken . Horn]

As a quick note, I did some Jasper profiling on a previous project (it 
was Jasper from 3.1, running inside weblogic 5.1). The single biggest 
runtime cost, was all the calls to Introspector.getBeanInfo(). I 
created a cache of these using a similar technique to FastHashMap in 
commons collections (in Fast mode), and lowered the runtime costs 
significantly (for the calls i looked at say, 60%! (I think)). It was a 
trivial fix for the large benefit. Introspector does all the work every 
time, and instantiates a new BeanInfo for each call. Also, the cache 
only needs to expand to contain all the tag classes - a fairly small, 
finite set.

I didn't submit it before, as it was at the time of Jasper4 / tag 
pooling being touted and thought the heavy runtime reflection stuff 
would be obsolete soon...

-Original Message-
From: costinm 
Sent: 27 March 2002 22:54
To: tomcat-dev; Kin-Man.Chung
Cc: costinm
Subject: Re: tag pooling question


On Wed, 27 Mar 2002, Kin-Man Chung wrote:

> Pulling codes out of iteration tag bodies is very high on my list of
> optimizations that I wnat to do.  I don't think we can do much about
> general scriplets that contain loops, though.
> 
> But before we start on jasper optimization work, we'll need benchmarks
> and performance analysers.  I have learnt from experience that 
performance
> improvement often comes from surprising places, and that optimizations
> done at the wrong time and place often do more harm than good.  
Benchmarks
> would give us some real metric for us to measure our optimization 
work,
> and analyzing tools would let us identify hot spots that need to be 
improved.
> 
> I'd appreciate comments, suggestions, and pointers on these two 
subjects.
> I'd also appreciate if anyone can donate some real life applications 
that
> I can use for benchmarking jasper performance.

The most usefull tools are OptimizeIt and ab. 

Simple pages would help much better then complex pages - first find
out what's the overhead of executin a simple JSP page, with no tags,
compare it with the equivalent servlet ( HelloWorld ), and find out
what's wrong. 

Then use a simple hello world Tag, compare it with the equivalent 
servlet ( or JSP not using tags ), and find what's wrong.

Same for a simple iteration tag, compared with a scriptlet

If you solve those simple problems, and get the tag version 
in a reasonable limit, I think we'll all be very happy  ( 30% slower 
would be acceptable for me, even 1/2 the speed of the equivalent 
scriptlet ).

Going after 'real life applications' when the simple hello world tag,
or a simple empty jsp page has a clear performance penalty would be a 
waste of time.

( all that with a reasonable load - I sugest 80 concurent requests )

Costin


--
To unsubscribe, e-mail:   
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: 
<mailto:[EMAIL PROTECTED]>



Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: tag pooling question

[costinm]

On Wed, 27 Mar 2002, Kin-Man Chung wrote:

> Pulling codes out of iteration tag bodies is very high on my list of
> optimizations that I wnat to do.  I don't think we can do much about
> general scriplets that contain loops, though.
> 
> But before we start on jasper optimization work, we'll need benchmarks
> and performance analysers.  I have learnt from experience that performance
> improvement often comes from surprising places, and that optimizations
> done at the wrong time and place often do more harm than good.  Benchmarks
> would give us some real metric for us to measure our optimization work,
> and analyzing tools would let us identify hot spots that need to be improved.
> 
> I'd appreciate comments, suggestions, and pointers on these two subjects.
> I'd also appreciate if anyone can donate some real life applications that
> I can use for benchmarking jasper performance.

The most usefull tools are OptimizeIt and ab. 

Simple pages would help much better then complex pages - first find
out what's the overhead of executin a simple JSP page, with no tags,
compare it with the equivalent servlet ( HelloWorld ), and find out
what's wrong. 

Then use a simple hello world Tag, compare it with the equivalent 
servlet ( or JSP not using tags ), and find what's wrong.

Same for a simple iteration tag, compared with a scriptlet

If you solve those simple problems, and get the tag version 
in a reasonable limit, I think we'll all be very happy  ( 30% slower 
would be acceptable for me, even 1/2 the speed of the equivalent 
scriptlet ).

Going after 'real life applications' when the simple hello world tag,
or a simple empty jsp page has a clear performance penalty would be a 
waste of time.

( all that with a reasonable load - I sugest 80 concurent requests )

Costin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: tag pooling question

[Kin-Man Chung]

Pulling codes out of iteration tag bodies is very high on my list of
optimizations that I wnat to do.  I don't think we can do much about
general scriplets that contain loops, though.

But before we start on jasper optimization work, we'll need benchmarks
and performance analysers.  I have learnt from experience that performance
improvement often comes from surprising places, and that optimizations
done at the wrong time and place often do more harm than good.  Benchmarks
would give us some real metric for us to measure our optimization work,
and analyzing tools would let us identify hot spots that need to be improved.

I'd appreciate comments, suggestions, and pointers on these two subjects.
I'd also appreciate if anyone can donate some real life applications that
I can use for benchmarking jasper performance.

Thanks in advance.

- Kin-man

> Date: Wed, 27 Mar 2002 15:31:54 -0600
> From: Casey Lucas <[EMAIL PROTECTED]>
> Subject: Re: tag pooling question
> To: Tomcat Developers List <[EMAIL PROTECTED]>
> MIME-version: 1.0
> Content-transfer-encoding: 7bit
> X-Accept-Language: en
> Delivered-to: mailing list [EMAIL PROTECTED]
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
> List-Post: <mailto:[EMAIL PROTECTED]>
> List-Subscribe: <mailto:[EMAIL PROTECTED]>
> List-Unsubscribe: <mailto:[EMAIL PROTECTED]>
> List-Help: <mailto:[EMAIL PROTECTED]>
> List-Id: "Tomcat Developers List" 
> 
> 
> That would be nice to have tag pooling in 4.x.  It was one of those things
> that I wanted to do before my day job changed a little.  Anyway, a few 
thoughts:
> 
> Tag pooling as implemented in 3.x is IMHO a good starting point, but generated
> code will really benefit if we can handle the more "traditional" optimizing
> compiler situations like pulling redundant code (i.e. tag setter methods) out 
of
> loops, etc.  Hopefully, with the recent talk of new jasper (very exciting), we
> can have a good place to easily integrate such optimizations.
> 
> If you have specific questions about 3.x tag pooling, just let me know... I 
might
> be able to remember some of it.
> 
> -casey
> 
> peter lin wrote:
> > 
> > thanks larry for that information.  I will take a look before I jump in.
> > 
> > Larry Isaacs wrote:
> > >
> > > This was done by Casey Lucas.  However, be aware that it comes
> > > with a disadvantage in that because of the extra code, it reduces
> > > the number of tags you can get on a JSP be for you hit Bug #6088
> > >
> > > <http://nagoya.betaversion.org/bugzilla/show_bug.cgi?id=6088>
> > >
> > > I'm doubtful you can get 100-300 tags on a JSP page in any version
> > > of Jasper.  Also, check recent posts on this list for a proposed
> > > "Jasper2" effort that is underway.  See:
> > 
> > Actually, I managed to make a page with about 140 tags that barely
> > squeezes under the 64K limit. Under moderate load it runs like a dog.
> > When I break it up into smaller pages using action include, it runs much
> > better.
> > 
> > >
> > > <http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg24054.html>
> > >
> > > Cheers,
> > > Larry
> > >
> > 
> > Peter lin
> > 
> > --
> > To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> 


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: tag pooling question

[Casey Lucas]

That would be nice to have tag pooling in 4.x.  It was one of those things
that I wanted to do before my day job changed a little.  Anyway, a few thoughts:

Tag pooling as implemented in 3.x is IMHO a good starting point, but generated
code will really benefit if we can handle the more "traditional" optimizing
compiler situations like pulling redundant code (i.e. tag setter methods) out of
loops, etc.  Hopefully, with the recent talk of new jasper (very exciting), we
can have a good place to easily integrate such optimizations.

If you have specific questions about 3.x tag pooling, just let me know... I might
be able to remember some of it.

-casey

peter lin wrote:
> 
> thanks larry for that information.  I will take a look before I jump in.
> 
> Larry Isaacs wrote:
> >
> > This was done by Casey Lucas.  However, be aware that it comes
> > with a disadvantage in that because of the extra code, it reduces
> > the number of tags you can get on a JSP be for you hit Bug #6088
> >
> > 
> >
> > I'm doubtful you can get 100-300 tags on a JSP page in any version
> > of Jasper.  Also, check recent posts on this list for a proposed
> > "Jasper2" effort that is underway.  See:
> 
> Actually, I managed to make a page with about 140 tags that barely
> squeezes under the 64K limit. Under moderate load it runs like a dog.
> When I break it up into smaller pages using action include, it runs much
> better.
> 
> >
> > 
> >
> > Cheers,
> > Larry
> >
> 
> Peter lin
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: tag pooling question

[peter lin]

thanks larry for that information.  I will take a look before I jump in.

Larry Isaacs wrote:
> 
> This was done by Casey Lucas.  However, be aware that it comes
> with a disadvantage in that because of the extra code, it reduces
> the number of tags you can get on a JSP be for you hit Bug #6088
> 
> 
> 
> I'm doubtful you can get 100-300 tags on a JSP page in any version
> of Jasper.  Also, check recent posts on this list for a proposed
> "Jasper2" effort that is underway.  See:

Actually, I managed to make a page with about 140 tags that barely
squeezes under the 64K limit. Under moderate load it runs like a dog.
When I break it up into smaller pages using action include, it runs much
better.


> 
> 
> 
> Cheers,
> Larry
> 

Peter lin

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: tag pooling question

[Larry Isaacs]

This was done by Casey Lucas.  However, be aware that it comes
with a disadvantage in that because of the extra code, it reduces
the number of tags you can get on a JSP be for you hit Bug #6088



I'm doubtful you can get 100-300 tags on a JSP page in any version
of Jasper.  Also, check recent posts on this list for a proposed
"Jasper2" effort that is underway.  See:



Cheers,
Larry

> -Original Message-
> From: peter lin [mailto:[EMAIL PROTECTED]] 
> Sent: Wednesday, March 27, 2002 8:10 AM
> To: [EMAIL PROTECTED]
> Subject: tag pooling question
> 
> 
> 
> Does anyone know who wrote the tag pool implementation for 
> TC3.3?  I am
> considering port/merging the TC3.3 tag pool code to TC4.0.x 
> jasper. I've
> been doing benchmarks with TC4.0.3 with and without coyote.  With JSTL
> getting close to release, I feel it would be a great benefit, since
> pages that use JSTL could easily use 100-300 tags. In my own 
> benchmarks,
> there is a major performance hit with pages that have 100+ tags under
> medium and heavy load.
> 
> thanks.
> 
> peter
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: