Community
Participate
Working Groups
Changing the classpath of a Java project (even an empty one) in 2.1.2 can take several seconds, especially when the classpath is large and the JDK is also being switched. Consider a case where about 25 average sized jars are being removed and 25 new jars added. Most of the processing appears to be in the Java indexer, which is on the background in most situations. It can take over 5-15 seconds even when nothing else is happening, and we have also seen cases where other tools have to wait for the indexer to complete before proceeding. Turning on tracing shows 60- 100ms for most jars, but up to 500+ ms per jar for some of the larger ones. This defect is being opened as a general request to look into performance improvements in modifying the classpath, especially in cases where many jars are being added and/or removed. If this has already been investigated or improved in v3 then feel free to close the defect, otherwise I would appreciate it if you can take another look into it. Thanks.
We have to open and parse all the JARs so as to ensure they are properly indexed. Any pending search query has to wait until the indexing has been completed. Note that there are ways for queries to notice that the indexing isn't finished in a non blocking way. Do you have anything particular in mind ?
Can you please check performance on M5 (once final M5 is declared) ? We made some improvements for bug 47213 which could improve what you're seeing.
I do see performance improvements in M5. We don't have our full plugin stack up to determine the actual %, but I will close this defect since it is definitely better. Thanks.
Verified for 3.0 M6 with build I200312162000. Use a test case with 3 directories containing each one 100 jar files for a cumulated size around 25Mb disk space. My box is a PIII-1GHz, 1Go RAM. To remove 100 files and add 100 new ones - 2.1.2: 7-8 seconds - 3.0 M6: 3-4 seconds
Verified, closing old bug.
