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.

Bug 48611 - [perf] excessive firing of events from MergedClasspath
Summary: [perf] excessive firing of events from MergedClasspath
Status: RESOLVED FIXED
Alias: None
Product: java
Classification: Unclassified
Component: Unsupported (show other bugs)
Version: 4.x
Hardware: All All
: P3 blocker (vote)
Assignee: issues@java
URL:
Keywords: PERFORMANCE
Depends on:
Blocks:
 
Reported: 2004-09-07 18:45 UTC by David Konecny
Modified: 2007-09-26 09:14 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
debugging patch (995 bytes, patch)
2004-09-07 18:47 UTC, David Konecny
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description David Konecny 2004-09-07 18:45:39 UTC
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)
Comment 1 David Konecny 2004-09-07 18:47:45 UTC
Created attachment 17446 [details]
debugging patch
Comment 2 Tomas Zezula 2004-09-13 13:20:26 UTC
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
Comment 3 David Konecny 2004-09-13 13:49:19 UTC
Tomas improved MergedClasspath but this change did not solve this issue.
Comment 4 Tomas Zezula 2004-09-13 13:56:30 UTC
It seems that the problem is in the JMManager. It calls cpRootResolved
approximatelly 800x for single unresolvedRoot.
Comment 5 David Konecny 2004-09-13 14:05:39 UTC
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.
Comment 6 Tomas Zezula 2004-09-13 20:21:14 UTC
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
Comment 7 David Konecny 2004-09-14 10:18:42 UTC
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. 
Comment 8 Jan Becicka 2004-09-14 10:37:53 UTC
Yes - these events are used for Scanning Progress Bar. What is wrong
with that?
Comment 9 David Konecny 2004-09-14 11:37:47 UTC
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?
Comment 10 Jan Becicka 2004-09-14 12:09:47 UTC
OK. We will take a look at it. Changing priority to P3 since the most
important part was fixed thanks to Tomas.
Comment 11 Martin Matula 2004-09-19 17:16:15 UTC
I am affraid that Tomas' fix removed code that made sure that the case
described by issue 49115 cannot occur.
Comment 12 Martin Matula 2004-09-19 17:18:03 UTC
Sorry - I meant issue 49256 (not 49115).
Comment 13 Jan Becicka 2004-09-20 08:11:14 UTC
Tomas' fix is *not* in beta2.
Beta2 build contains MergedClassPathImplementation 1.6 and JMManager
1.51.4.1
Comment 14 ehucka 2005-01-11 13:19:37 UTC
old target milestone, please re-evaluate
Comment 15 Tomas Zezula 2005-01-28 14:08:25 UTC
I think this was already fixed.
Comment 16 Jan Becicka 2005-09-29 16:48:20 UTC
This one was already fixed.
Comment 17 Quality Engineering 2007-09-20 09:48:42 UTC
Reorganization of java component