United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-5081166 Regain performance degradation from 1.5 b40 for deeply inherited classes -- speed up
JDK-5081166 : Regain performance degradation from 1.5 b40 for deeply inherited classes -- speed up

Details
Type:
Bug
Submit Date:
2004-07-31
Status:
Open
Updated Date:
2009-06-02
Project Name:
JDK
Resolved Date:
Component:
docs
OS:
other
Sub-Component:
doclet
CPU:
generic
Priority:
P4
Resolution:
Unresolved
Affected Versions:
5.0
Targeted Versions:
5.0-pool

Related Reports

Sub Tasks

Description
This is a follow-on to bug 
5048019: Huge performance regression in javadoc in Tiger b40 for deeply inherited classes

Dear Sirs,

I don't consider this bug as beeing fixed in Tiger (1.5) build b59 as stated in 
http://java.sun.com/j2se/1.5.0/snapshots/jdk15.b59.bugsfixed.list.html. My small 
test showing the problem uses ten classes (see below) extending JPanel.

Using the follwing command:

javadoc -sourcepath . -classpath . -subpackages de -breakiterator -d ./doc -private -encoding iso8859-1 -use -splitindex

for jdk1.4.2_04, jdk1.5.0-beta3-b57 and jdk1.5.0-beta3-b59 gives me the 
following execution times on my system:

jdk version        | time/sec. | factor
---------------------------------------
jdk1.4.2_04        |     6.5   |  1.0
jdk1.5.0-beta3-b57 |    90.0   | 13.8
jdk1.5.0-beta3-b59 |    37.4   |  5.8

Even jdk1.5.0-beta3-b59 is more than two times faster than jdk1.5.0-beta3-b57 it 
is still a lot slower (about six times) than jdk1.4.2_04 which makes it nearly 
useless for large projects. Please do invest some more time to resolve this 
problem.

Best regards,
MG


Sample classes used for my test:

package de.mypackage;
import javax.swing.*;
/**
 * A derived JPanel.
 */
public class MyPanel0 extends JPanel {
    /**
     * Create a new MyPanel0 object.
     */
    public MyPanel0() {
        super();
    }
    /**
     * A dummy method.
     *
     * @param aValue    The value to be returned from this method.
     *
     * @return  The value given to this method.
     */
    public int someMethod(int aValue) {
        return aValue;
    }
}

package de.mypackage;
import javax.swing.*;
/**
 * A derived JPanel.
 */
public class MyPanel1 extends JPanel {
    /**
     * Create a new MyPanel1 object.
     */
    public MyPanel1() {
        super();
    }
    /**
     * A dummy method.
     *
     * @param aValue    The value to be returned from this method.
     *
     * @return  The value given to this method.
     */
    public int someMethod(int aValue) {
        return aValue;
    }
}

package de.mypackage;
import javax.swing.*;
/**
 * A derived JPanel.
 */
public class MyPanel2 extends JPanel {
    /**
     * Create a new MyPanel2 object.
     */
    public MyPanel2() {
        super();
    }
    /**
     * A dummy method.
     *
     * @param aValue    The value to be returned from this method.
     *
     * @return  The value given to this method.
     */
    public int someMethod(int aValue) {
        return aValue;
    }
}

package de.mypackage;
import javax.swing.*;
/**
 * A derived JPanel.
 */
public class MyPanel3 extends JPanel {
    /**
     * Create a new MyPanel3 object.
     */
    public MyPanel3() {
        super();
    }
    /**
     * A dummy method.
     *
     * @param aValue    The value to be returned from this method.
     *
     * @return  The value given to this method.
     */
    public int someMethod(int aValue) {
        return aValue;
    }
}

package de.mypackage;
import javax.swing.*;
/**
 * A derived JPanel.
 */
public class MyPanel4 extends JPanel {
    /**
     * Create a new MyPanel4 object.
     */
    public MyPanel4() {
        super();
    }
    /**
     * A dummy method.
     *
     * @param aValue    The value to be returned from this method.
     *
     * @return  The value given to this method.
     */
    public int someMethod(int aValue) {
        return aValue;
    }

Additional classes missing because of size limit for comments.


2004-07-28 18:31:49
f?ge

Hello,

I agree with mgoe, because my experience is much the same.

Generating javadoc for my framework took around one minute from 1.4 up to 1.5beta2,
but with 1.5beta3-b55 it took about 9 minutes, whereas now, under b59, it takes 4 minutes: still four times longer!

The number of jdk source files to lookup increased in the tiger release "only" by 20-25 percent,
so this performance decrease of javadoc is not a decoration in the evolution of the java platform.

Regards
AF
###@###.### 10/15/04 03:44 GMT

                                    

Comments
EVALUATION

###@###.### said:
 I believe the new language features dictate that we live with this
 performance degradation for 1.5.

 These numbers show that we are doing better.  I'm sure there are ways to
 rearchitect certain parts of the doclet to make it run faster but I don't know
 of any off the top of my head.

 Another reason for the decrease in performance is the toolkit, which kind of
 acts as a middle man so that doclets can share code.  If you cut out the middle
 man, I have a feeling the doclet will run faster but then we would have no
 toolkit.

 Improving performace is a good project for a future release.

###@###.### 2004-07-30
                                     
2004-07-30
WORK AROUND

This problem can sometimes be solved by doubling the amount of maximum memory
 used by javadoc pre-5.0.  For example, change -J-Xmx128M to -J-Xmx256M.
###@###.### 10/15/04 03:44 GMT
                                     
2004-10-15



Hardware and Software, Engineered to Work Together