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 fast open for a file after the new BuildSys was integrated. Unlike the issue 41072, the regression of fast open is significant when some files are already open in the editor. So this is a different problem than issue 41072. Notice that the regression is measureable for JTable.java, but not for Main20kB.java (which is in my small local FS). 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) Fast opening JTable.java after the IDE starts with a Main.java already open in the editor W2K: 200403141900 - 3281ms, 3141ms, 3344ms 200403161900 - 5296ms, 5188ms, 5093ms Linux: 200403141900 - 4026ms, 4157ms, 4022ms 200403161900 - 8186ms, 5573ms, 10806ms 2) Fast opening Main20kB.java after the IDE starts with a Main.java already open in the editor W2K: 200403141900 - 984ms, 1032ms, 750ms 200403161900 - 922ms, 796ms, 938ms Linux: 200403141900 - 2215ms, 1489ms, 1822ms 200403161900 - 1916ms, 1637ms, 1641ms
The slowish opening of java file is not happing only with fast open (ALT+SHIFT+O), but also with the "Show selected TODO in editor" functionality of To Do window. For example for the file org.netbeans.core.xml.EntityCatalogImpl fast opening via ALT+SHIFT+O takes 17 seconds on my W2K machine, while opening from To Do window takes 18 seconds. Opening this file straight from the Projects tab directory structure takes around 3 seconds (doing it as the first thing after IDE start).
Opening EntityCatalogImpl takes less than a second on my machine. With code folding turned off. Have you tried w/ and w/o code folding?
W/ the codefolding. When you turn the code-folding off, opening files is fast. In the thread dump (see attached) you can see that FoldMaintainer invokes parser which perhaps takes all the time. But why it takes soooo long? Mila, your turn. ;o)
Created attachment 14460 [details] Thread Dump when opening a java file w/ code-folding turned on.
At least in this thread dump, FileUtil.isArchiveFile is taking the time. Of course this is just a random snapshot.
Well what we may try for testing purposes is to do nothing in FoldMaintainer.initFolds() and leave the folds creation for later - when someone else (e.g. NavigationView) asks for reparse which will notify the editor (or the editor may ask for reparse lazily as well). I'll try to experiment with that.
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?
New numbers with the same configuration, last trunk build before merge of refactoring. 1) Fast opening JTable.java after the IDE starts with a Main.java already open in the editor W2K: 200406011800 - 3875ms, 4329ms, 4250ms Linux: 200406011800 - 4310ms, 4734ms, 6816ms 2) Fast opening Main20kB.java after the IDE starts with a Main.java already open in the editor W2K: 200406011800 - 844ms, 937ms, 797ms Linux: 200406011800 - 1134ms, 925ms, 982ms This means that fast opening Main20kB.java from my project's src is not a regression at all. An issue is still fast opening classes from JDK's sources.
Seems that the performance optimalization of ClassPath and queries helped. There is no regression for project files and the regression for JDK files is lower. The question is what part of the regression is related to build system? Tondo, could you measure some hot spots of the fast open?
Yeah, I am looking into it.
I've look on it in the OptimizeIt and I haven't find a problem related to the BuildSystem. The original slow down of the open was caused by queries and classpath. All these issues were fixed. Biggest regression was in the queries, all queryImpls was used. This has changed and FileUtil.isArchiveFile was removed from ClassPathProviders. Also the queriesImpls and CLassPathProviders were ordered.
verified in NB5.0 (200511281900) To Do window open [ ms ] / 1000 ms 1st usage 872 1125 972 531 770 Subsequent usage 311 277 257 109 156