I'm using Jasper in Weblogic from tomcat 3.1 (ish, we've patched a couple
of things too). While profiling some of my JSP's, I see the
JspRuntimeLibrary.introspectHelper consuming between 40-70% of the time,
and a large %age of the object creation. Drilling down, most of the time is
the line (which is still in Jasper34)
java.beans.BeanInfo info
= java.beans.Introspector.getBeanInfo(bean.getClass());
Which in turn is slow due to the construction of the BeanInfo (concrete class:
GenericBeanInfo)
So my question is: why isn't this cached? Or rather, if I were to cache this object,
what are my problems?
Those I see so far are:
1) If it's cached, where is the cache held?
(a) If within JspRuntimeLibrary, I must synchronize the Map --
may cause a bottleneck between threads, since this is called hundreds of times per JSP.
(b)If not here, then perhaps on the thread -- we're using our own subclass at this
point (most of the time)
so I could store it as a thread local there, or change the generation to pass in a
storage object / cache.
2) Will this prevent class reloading from GC'ing the old classes, unless the map is
released? For our app,
reloading is only a dev feature so not too worried about this.
3) Am I reading my profiler wrong and this shouldn't be a bottleneck?
I don't think we can wait long enough for the Jasper refactoring to happen, so am
looking for smallish
changes currently.
Ken.
This e-mail message is CONFIDENTIAL and may contain legally privileged
information. If you are not the intended recipient you should not read,
copy, distribute, disclose or otherwise use the information in this e-mail.
Please also telephone or fax us immediately and delete the message from
your system. E-mail may be susceptible to data corruption, interception
and unauthorised amendment, and we do not accept liability for any such
corruption, interception or amendment or the consequences thereof.
