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 Jun19, Linux, JDK1.5.0b55 Alt-G on some method method often causes heavy parsing leaving the IDE nonresponsive for a significant time like tens of seconds. Sometimes it even causes OutOfMemory errors if I have larger set of project. It seems to me that most of the work comes from NbJavaJMISyntaxSupport.buildGlobalVariableMap. I added tracing to ASTProvider.createASTree and 100 source files (mostly from src.zip) can be parsed in order to complete one action. I will attach root of typical stack trace tha can be dumped during the action.
Created attachment 15853 [details] stack trace
Radime, as there were certain improvements done could you please check this again? Also could you be more concrete and give us some concrete cases and numbers that we can work with and improve? Thanks.
Milo, I think this problem is not fixed completely. I was able to get up to 20 seconds, though in majority of the cases the times were reasonable (up to ~1-2 seconds). I did not find any reproducible case.
Well, it's tough. I'm confident that the code for this feature on the editor side does not take up 20 secs. It's likely some dependent java parsing being done on the background that causes slowness of this feature which, unfortunately, resides in the editor module so that is the place where the bugs are entered against ;) Tondo, if it happens to you again, could you please try to catch some thread dumps to confirm or reject that idea of background parsing being done? Thanks.
Downgrading to P3. This is a random behavior and in majority of cases the responsiveness of the action is reasonable.
Created attachment 16309 [details] thread dump
In o.n.editor.Completion 391:38 press Alt-G to go to JDCPopupPanel. One thread dump is attached. I hope it helps.
I've ran the IDE in OptimizeIt but unfortunately I did not experience an extra slowness on the usecase that Radim provided. BTW I have found one particular place where the SourceCookie.Editor (implemented by JavaParserGlue) gets used. I guess that it could be worth to eliminate the SourceCookie.Editor use and go directly through JMIs. Attaching the stacktrace.
Created attachment 16351 [details] Use of Java Hierarchy
Eliminating SourceCookie.Editor use. Checking in JMIUtils.java; /cvs/editor/src/org/netbeans/modules/editor/java/JMIUtils.java,v <-- JMIUtils.java new revision: 1.32; previous revision: 1.31 done Checking in JavaKit.java; /cvs/editor/src/org/netbeans/modules/editor/java/JavaKit.java,v <-- JavaKit.java new revision: 1.92; previous revision: 1.91 done Checking in NbJMIResultItem.java; /cvs/editor/src/org/netbeans/modules/editor/java/NbJMIResultItem.java,v <-- NbJMIResultItem.java new revision: 1.16; previous revision: 1.15 done Checking in NbJavaJMISyntaxSupport.java; /cvs/editor/src/org/netbeans/modules/editor/java/NbJavaJMISyntaxSupport.java,v <-- NbJavaJMISyntaxSupport.java new revision: 1.20; previous revision: 1.19 done
Changing subcomponent to navigation.
Changed target milestone to TBD.
I guess we can close it now.