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 something wrong in MergedClasspath class. It fires too many events! I will attach trivial patch of Classpath class which dumps line to output whenever sombody calls Classpath.firePropertyChange and there is somebody listening on that event. The patch also counts total number of fired events. Numbers are pretty suspicious. 1.) When you open one empty Java Application project you will see that one instance of MergedClassPathImplementation fires 50 events (25x ENTRIES property and 25x ROOTS property). 2.) When you open 15 empty Java Application projects you will see that the same instance will fire 920 events! Again half are Entries, half are Roots. 3.) If you modify classpath of one project and press OK in customizer, you will get another 920 events. All events are fired from: at_java.lang.Thread.dumpStack(Thread.java:1064) at_org.netbeans.api.java.classpath.ClassPath.firePropertyChange(ClassPath.java:414) at_org.netbeans.api.java.classpath.ClassPath$SPIListener.propertyChange(ClassPath.java:641) at_java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:252) at_org.netbeans.modules.javacore.classpath.MergedClassPathImplementation.firePropertyChange(MergedClassPathImplementation.java:209) at_org.netbeans.modules.javacore.classpath.MergedClassPathImplementation.classPathRootResolved(MergedClassPathImplementation.java:146) at_org.netbeans.modules.javacore.JMManager.resolveCPRoot(JMManager.java:895) at_org.netbeans.modules.javacore.JMManager.resolveCodebases(JMManager.java:804) at_org.netbeans.modules.javacore.JMManager$2.run(JMManager.java:778) at_org.openide.util.Task.run(Task.java:136) at_org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:330) at_org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:686) and the only listener is attached at: at_java.lang.Thread.dumpStack(Thread.java:1064) at_org.netbeans.api.java.classpath.ClassPath.addPropertyChangeListener(ClassPath.java:351) at_org.netbeans.modules.javacore.JMManager.<init>(JMManager.java:201) at_org.netbeans.modules.javacore.internalapi.JavaMetamodel.getManager(JavaMetamodel.java:47) at_org.netbeans.modules.javacore.JavaCoreModule.restored(JavaCoreModule.java:66)
Created attachment 17446 [details] debugging patch
There should be smoe events firing (for each classpath which has changed 1 event + for each resource which has been added/removed 2 events). But this should be much more less. I will try to add one more fix which will remove the scanning for resources which are already scanned on other classpaths. Checking in javacore/src/org/netbeans/modules/javacore/classpath/MergedClassPathImplementation.java; /cvs/java/javacore/src/org/netbeans/modules/javacore/classpath/MergedClassPathImplementation.java,v <-- MergedClassPathImplementation.java new revision: 1.7; previous revision: 1.6 done
Tomas improved MergedClasspath but this change did not solve this issue.
It seems that the problem is in the JMManager. It calls cpRootResolved approximatelly 800x for single unresolvedRoot.
The number "800" depends on the number of opened projects. For one opened project it is about 50, for 15 projects it is around 800. And even on 15 open projects the IDE slowdown (when modifying classpath) is clearly visible.
JMManager throws away the computed unresolved roots and resolves all (even already resolved roots). I don't know why, it is not needed and it is not documented to be some workaround. I removed it and it did not hurt anything, at least it seems so. :-) The firing is now no more related to the number of opened projects. Checking in src/org/netbeans/modules/javacore/JMManager.java; /cvs/java/javacore/src/org/netbeans/modules/javacore/JMManager.java,v <-- JMManager.java new revision: 1.52; previous revision: 1.51 done
I verify that modifying project's classpath is fixed - only expected amount of events is fired. Thanx. But the problem persist for project opening. Testcase: start IDE; create an empty Java Application; wait till everything is parsed; restart IDE. After IDE startup about 50 events is fired for the one project opening.
Yes - these events are used for Scanning Progress Bar. What is wrong with that?
OK, the most immportant part of this problem was fixed, so the rest is up to you. I'm not that much interested in it. What I think is wrong is this. In my case I have 15 empty projects. Each project has two source paths (src and test) and on classpath they have the same JDK and tests has the same junit.jar. That means I have 32 unique items to be parsed (for sake of example I count JDK as one item although it is in total about 5-10 items; no big diff). So what I would expect is that progress bar of loading/checking MDR caches has about these 32 steps/events (+initialization, etc.). In your current implementation you fire 800 events instead of 32! That's what I think is wrong. I expect that your listener is updating progress bar after each event, right? Means it has to schedule redraw in AWT thread, etc. As I said this is minor compared to the problem fixed by Tomas, but I think it is still worth to fix. Performance gains are about small steps and this one seems it should be simple to fix. So why not to do that?
OK. We will take a look at it. Changing priority to P3 since the most important part was fixed thanks to Tomas.
I am affraid that Tomas' fix removed code that made sure that the case described by issue 49115 cannot occur.
Sorry - I meant issue 49256 (not 49115).
Tomas' fix is *not* in beta2. Beta2 build contains MergedClassPathImplementation 1.6 and JMManager 1.51.4.1
old target milestone, please re-evaluate
I think this was already fixed.
This one was already fixed.
Reorganization of java component