JDK-5081166 : Regain performance degradation from 1.5 b40 for deeply inherited classes -- speed up
  • Type: Bug
  • Component: tools
  • Sub-Component: javadoc(tool)
  • Affected Version: 5.0
  • Priority: P4
  • Status: Resolved
  • Resolution: Won't Fix
  • OS: other
  • CPU: generic
  • Submitted: 2004-07-31
  • Updated: 2014-10-28
  • Resolved: 2014-10-28
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
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
15-10-2004

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
30-07-2004