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.
dev build from 2004, Oct 20, JDK1.5.0 When starting the IDE with existing project setup and some file opened in editor there are three calls to parse the content of file. The first pair is probably result of some bad logic in ResourceImpl and these are triggered by fold manager from editor. The third one follows after classpath initialization. Also there are two requests to parse all files in inheritance tree (at least some of them related to override annotations processing). And there is yet another request for parsing of java.lang.String. This can be related to searching of main classes.
Created attachment 18424 [details] log file
I attached log file with some thread dumps showing stacks of calls to ASTProvider and possible place in fold manager that asks for parsing.
I am going to fix the "bad logic" that causes the initial parse to be repeated as mentioned by Radim.
I've fixed the bad logic. It could have caused several other parses than the redundant parse of Main class. Radime, please measure the results and provide us with an updated log. Thanks!
I am attaching very simple diffs for java and editor modules which eliminate parsing at startup, before the classpath scan is finished. This takes the number of parses for a single file after startup to one. Performance folks, please evaluate and decide whether these should be integrated.
Created attachment 18449 [details] Diff to be applied in nb_all/editor
Created attachment 18450 [details] Diff to be applied in nb_all/java
Martine, should not the same be applied to the override anotation support too?
Maybe it should. What I did was I added a thread dump to the parser so that I could detect what triggers the parsing during the startup. The two places in the code that I added the waitScanFinished call into were the only two I saw. After I added waitScanFinished to these two places, I didn't see any parsing during the startup anymore. But it could be a race condition.
*** Issue 50536 has been marked as a duplicate of this issue. ***
The percieved performance with the patch is a bit different. Classpath scanning dialog is shown quickly after main window is displayed and when it is completed the fold and navigation view is update (this can last couple of seconds if a large file is opened). The time to start the IDE with java.awt.Component + 5 other files opened till no UI activity on my Linux 2GHz, 1GB, JDK 1.5.0. With the patch: 29.5, 30.3, 29.4, 32 W/o: 34.4, 26.0, 34.7, 26.0, 33.9 So the patch improves bad cases but there are some cases when we are faster even with current approach. I do not know why. It seems the may defer this integration for 4.0 and use it in 4.1 and maybe do somefurther tuning.
OK, after agreement with Radim, we are going to defer this to 4.1 and keep it as a P3 issue.
So - should we apply this patch to trunk?
Personally I think we should but we probably need to check and measure it again before applying. Is it uptodate?
I will attach recent updated diffs - Honzo & Dafe please review.
Created attachment 19860 [details] Diff to be applied in nb_all/java
Created attachment 19861 [details] Diff to be applied in nb_all/objectbrowser
Yo, reviewed and thanks. I guess part to be applied to objectbrowser/navigator has the effect that navigator content will be filled *after* class scanning is complete, right? I always wanted to do this, but didn't know how ;-)
Yes, Dave. And the diff to navigator also fixes one bug which should be fixed even if we do not apply these diffs - please make sure you start the transaction out of the try-finally block, not inside it. This is because if beginTrans fails, no transaction is open, so it would be a mistake to call endTrans in finally.
The java module patch looks fine.
Fixed. Checking in editor/src/org/netbeans/modules/editor/java/NbJavaFoldManager.java; /cvs/java/editor/src/org/netbeans/modules/editor/java/NbJavaFoldManager.java,v <-- NbJavaFoldManager.java new revision: 1.4; previous revision: 1.3 done Processing log script arguments... More commits to come... Checking in src/org/netbeans/modules/java/JavaEditor.java; /cvs/java/src/org/netbeans/modules/java/JavaEditor.java,v <-- JavaEditor.java new revision: 1.185; previous revision: 1.184 done Processing log script arguments... More commits to come... Checking in src/org/netbeans/modules/java/ui/nodes/elements/ChildrenProvider.java; /cvs/java/src/org/netbeans/modules/java/ui/nodes/elements/ChildrenProvider.java,v <-- ChildrenProvider.java new revision: 1.7; previous revision: 1.6 done Checking in navigator/javanavigation/src/org/netbeans/modules/javanavigation/ClassMemberModel.java; /cvs/objectbrowser/navigator/javanavigation/src/org/netbeans/modules/javanavigation/ClassMemberModel.java,v <-- ClassMemberModel.java new revision: 1.25; previous revision: 1.24 done Checking in navigator/javanavigation/src/org/netbeans/modules/javanavigation/InheritanceTreeModel.java; /cvs/objectbrowser/navigator/javanavigation/src/org/netbeans/modules/javanavigation/InheritanceTreeModel.java,v <-- InheritanceTreeModel.java new revision: 1.9; previous revision: 1.8 done
Reorganization of java component