JDK-8294880 : Review running time of jdk/internal/shellsupport/doc/JavadocHelperTest.java
Type:Sub-task
Component:tools
Sub-Component:javadoc(tool)
Affected Version:20,21
Priority:P4
Status:Resolved
Resolution:Fixed
Submitted:2022-10-06
Updated:2024-05-23
Resolved:2024-05-15
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.
A pull request was submitted for review.
URL: https://git.openjdk.org/jdk/pull/18837
Date: 2024-04-18 12:11:56 +0000
18-04-2024
[~darcy] I created as PR to move the original test to langtools tier2 and speed up the tier1 test.
https://github.com/openjdk/jdk/pull/18837
18-04-2024
As a decision-making aid, looking only at the first class in each module exports speeds up the test from 1:30 mins to 17 secs on my laptop, only looking at the first enclosed element of the first class further speeds it up to 12 secs.
26-03-2024
The test in question performs nested iterations over the following sets:
modules > exports directives > classes > enclosed elements
As expected, the primary cause for the slow performance is the number of classes (around 7000), followed by enclosed elements (about 18 per class). So the easiest way to speed up the test would be to limit the classes we look at.
So the questions are:
- Would it be enough to look at a fixed number of classes per module/exports directive such as the first n classes, or maybe a share such as 1 in x?
- Would that be sufficient for the purpose of the test or do we still want a "full" mode that looks at every single class?
26-03-2024
After a "thoroughness" knob for testing is developed, applying that knob to only resolve a subset of the javadoc sources may be useful to speed up the test in the common case.
06-10-2022
FWIW, the test is resolving javadoc for all the JDK sources, to verify the resolution code can handle it. Besides making the resolution code (much) faster, the only other option might be to limit which elements are tested by the test.