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  customer .
     */
    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  customer .
     */
    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  customer .
     */
    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  customer .
     */
    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  customer .
     */
    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
  xxxxx@xxxxx   10/15/04 03:44 GMT

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.
  xxxxx@xxxxx   10/15/04 03:44 GMT

  xxxxx@xxxxx   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.

  xxxxx@xxxxx   2004-07-30

Hello

I can confirm the time observations by MGOE  This bug increments the creation time of our software by 30 minutes. Please fix it.

Best regards
Andreas Barth

We experienced a large degradation as well (our documentation is produced from hundreds of source files).  Our doc production time went from about 5 minutes to some time greater than 45 minutes (we got tired of waiting for it at that point).

We were passing a max memory parameter of 128M to the javadoc tool.  I noticed that if I double that to 256M, the javadoc creation time decreases back down near where it was before (around 5 minutes).

For those having trouble, does passing a larger max memory parameter make a great difference in your 1.5 javadoc generation times?

It is clear to me that the memory footprint of the javadoc tool has increased greatly.

We experienced a large degradation as well (our documentation is produced from hundreds of source files).  Our doc production time went from about 5 minutes to some time greater than 45 minutes (we got tired of waiting for it at that point).

We were passing a max memory parameter of 128M to the javadoc tool.  I noticed that if I double that to 256M, the javadoc creation time decreases back down near where it was before (around 5 minutes).

For those having trouble, does passing a larger max memory parameter make a great difference in your 1.5 javadoc generation times?

It is clear to me that the memory footprint of the javadoc tool has increased greatly.

For our large project the workaround found by heydowns seems to work (thank you very much). For my example given above increasing the max memory does not help. The measured duration is the same as for jdk1.5.0-beta3-b59.

Martin Goettlicher