This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
There is a significant performance regression in trunk in opening a file in the editor after the new BuildSys was integrated. Here are results from testing on W2K (Dell Precision 220, PIII 800MHz, 512MB RAM, Windows 2000) and Linux (Dell Latitude C840, PIV 2.2GHz, 1024MB RAM, Red Hat 9). Each test was repeated three times. 1) Opening Main20kB.java as a first file after start W2K: 200403141900 - 1312ms, 1250ms, 1266ms 200403161900 - 1875ms, 1860ms, 1859ms Linux: 200403141900 - 1262ms, 1692ms, 1191ms 200403161900 - 2180ms, 2066ms, 1729ms 2) Opening Main20kB.java after the IDE starts with a Main.java already open in the editor W2K: 200403141900 - 1078ms, 859ms, 922ms 200403161900 - 938ms, 953ms, 719ms Linux: 200403141900 - 989ms, 995ms, 1041ms 200403161900 - 1046ms, 1813ms, 954ms
The only additional overhead introduced by new build system is time spent in queries. The queries was significantly improved. Could someone perform new analyzes on build without refactoring?
The same configuration, last trunk build before merge of refactoring. 1) Opening Main20kB.java as a first file after start W2K: 200406011800 - 1797ms, 1719ms, 1609ms Linux: 200406011800 - 2946ms, 2870ms, 3019ms 2) Opening Main20kB.java after the IDE starts with a Main.java already open in the editor W2K: 200406011800 - 610ms, 563ms, 594ms Linux: 200406011800 - 866ms, 864ms, 854ms Assigning the bug to myself. I will have a look at the first opening of java file in profiler.
Tomasi, great portion of the first file opening time is spent in JCFinderFactory.getFinder() and in JCBaseFinder.getExactPackage(), see the attached call tree from profiler.
Created attachment 15448 [details] Screenshot of jprofiler's call tree window
The JCFinderFactory was removed during MDR merge and JCBaseFinder can now behave completely different.
In general, throw out any performance data you might have had regarding the editor, parser database, etc., since it is all quite different after the refactoring merge.
According to the JProfiler screenshot it seems that the most time is spent in the editor module. But the JCClass stuff was completely redesign, probably the bug is obsolete.
Yes. This issue can be closed. The main performance problem was caused by creation of JCBaseFinders, where parserDB files were read from disk and memory parserDBs were created. This took 1600ms. Parser DB files were replaced by MDR, behaviour is different.
OK, forget this bug. I have entered a fresh one ;-) See issue 44661.