JDK-4520754 : Introspector Performance can be optimized by reducting exceptions
  • Type: Enhancement
  • Component: client-libs
  • Sub-Component: java.beans
  • Affected Version: 1.4.0
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_nt
  • CPU: x86
  • Submitted: 2001-10-29
  • Updated: 2002-04-27
  • Resolved: 2002-04-27
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.4.1 hopperFixed
Related Reports
Relates :  
Description
One of the most unfortunate design idioms which affect the performance of the Introspector is the seach for an explicit Beaninfo class. The findExplicitBeanInfo() catches exceptions as part of it's control flow as it searches for and tries to instatiate a BeanInfo. In the normal course of searching for an BeanInfo class, 8 exceptions will be thrown and caught before the method returns null. THATS 8 EXCEPTIONS DURING NORMAL CONTROL FLOW!

Throwing an exception is a costly operation since an Exception object has to be created and thrown. The stack has to be traced back and filled with a bunch of little strings. 

The native method fillInStackTrace take about 9.2% of the time in the Introspector performance test for a total of about 21.5 seconds. The same test with the call to findExplicitBeaninfo() method call commented out takes just under 10 seconds. Clearly if we can avoid some of the exceptions then it will go a long way toward better Introspector performance.

Introspector Performance Tips:

The best performance in the Introspector can be achieved by providing an explicit BeanInfo in the same package as the JavaBean.

Some suggestions for reducing thrown Exceptions. The 1.2 ClassLoader is a delegation class loader. Is there a possiblility that there are redundant calls being made by trying different classloaders in the instantiate() method? The SystemClassLoader was added as a result to the fix for 4168475 and the Context ClassLoader from the current Thread was added for JWS support and 4348152. If these two ClassLoader calls can be removed then we can cut down the number of exceptions to 4.

A further reduction is that the BeanInfo search path has a default value of "sun.beans.infos" by default. There is only one class in this package, ComponentBeanInfo, yet this is executed for every class which doesn't have an explicit BeanInfo. The ComponentBeanInfo should be moved to the java.awt package. If the BeanInfo search path was an array of empty Strings, then this would cut out 4 exceptions upon each iteration. The performance test executes in 16 seconds when Introspector.setBeanInfoSearchPath(new String[]) is set.

Coupled with the reduction in classloader searches, the number of exceptions would be cut to 2 per iteration - which is significantly beter than 8. 

Introspector Performance Tips:

* The best performance in the Introspector can be achieved by providing an explicit BeanInfo in the same package as the JavaBean.

* Set the Introspector BeanInfo search path to an empty String[]. Side affect: you may see more properties for Component.

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: hopper FIXED IN: hopper INTEGRATED IN: hopper
14-06-2004

PUBLIC COMMENTS .
10-06-2004

EVALUATION Should write tests. This should be done for tiger or hopper if possible. ###@###.### 2001-11-16 One good optimation can be found in findExplicitBeanInfo. It seems like all classes search in the package "sun.beans.infos" for explicit BeanInfo while currently the only bean info which resides in that package is ComponentBeanInfo. We should only look for that case and ignore all others. The risk of the above optimation is if application has stored their bean infos in the sun.beans.infos package then they will no longer be picked up. As part of this fix, the default search path "sun.beans.infos" should no longer be referenced. As an experiment I removed the call to the class loader of the currrent class (Class.forName(className)) and I didn't experience any adverse side effects. This makes sense since that situation would be covered by the Thread.currentThread().getContextClassLoader(). These changes significantly cut down on the number thrown Exceptions used for control flow. ###@###.### 2002-04-03
03-04-2002