Umbrella issue to track UML performance analysis for 6.0.
Proposed scenarios for improvement in NB 6.0:
1) Reverse engineer a large project. I usually use uml core project as a test
case. It contains about 3000 classes.
2) Open an existing diagram.
3) Open an existing UML project.
4) Right click in the model explorer of a large UML project. This may already
be solved with the "core" patch available on the hotfix UC.
1) Expand Model -> org -> netbeans -> modules -> uml -> core -> reverseengineering
2) right-click on reframework -> CDFS -> Class Diagram, click finish
3) answer yes to scoped element popup
Additional observations From Marian:
... I went through all the issues you mentioned, from my short experience with
UML I can say only: That's really slow ;( - I mean:
- reverse engineering of jEdit takes >5 minutes
- generating class diagram takes about 45 seconds
- multi selection of nodes from UML project takes 5-10 seconds
- popup is also slower than 100 ms for sure
- slow startup time with UML pack
- huge amount of data in userdir - without touching any UML functionality
... on my notebook (TM 8104 / Intel PM 2GHz 1GB).
jEdit reverse engineering:
jEdit project reverse engineering. It took > 7 minutes to reverse engineer the sources. (under profiler)
Here are some comments:
- The reverseEngineer method took 99.9% of the time
- It looks like UML uses it's own parser instead of the NetBeans one. Probably the parser is not optimized so the NB
parser should be considered.
- During the parsing there are two parts that take the most of the time: UMLParser.processStreamFromFile() and
UMLParsingIntegrator.integrate(). Other calls do not have big impact.
- the XMLManip.selectSingleNode had the highest self time. Also, there are some other methods from the XMLManip and
UMLXMLMAnip classes in the top of the list.
- The thread UML is working in is called Logging Flush. Is this by design?
The only strange think we noticed is the ImageFetcher thread. When user creates a diagram 1-3 such threads starts. For
each new diagram these threads are started but as soon as we have 21 threads no more threads will be created. This is
probably OK, but taking into account that ImageFetcher.run() took the most of the time this may be interesting to look at.
Scenario: Expanding Models node of reverseengineered JEdit Project (first attempt):
Most of time during this operation IDE spends in o.n.m.uml.ui.nodes.UMLModelElementNode.initialize() method (98 % of time)
This method calls registerForLifeTimeEvents() and registerForNamedElementEvents() methods.
In this methods I see a lot of calls of o.n.m.uml.ui.nodes.UMLModelElementNode.equals() method. It looks like every node
in tree compares with every other node. (For 228 calls of UMLModelElementNode.initialize() I see about 80000 equals() calls)
Scenarios: Invoking popup menu and selecting multiple nodes:
During this scenarios most of time are spending calling o.n.m.uml.ui.nodes.UMLModelElementNode.equals() method and also
it takes long time to retrieving data from o.n.m.uml.propertysupport.DefinitionPropertyBuilder.retrieveProperties() to
It is also important to mention that these operations (UMLModelElementNode.equals()and
DefinitionPropertyBuilder.retrieveProperties()) are invoked in the AWT thread so they may block the IDE
>- reverse engineering of jEdit takes >5 minutes
1.1 the day the "5 minutes" report was sent
on nb-perf (ie. 06/05/07) i measured it on then
current build at less than 1 minute using downloaded
current jEdit (about 390) files
1.2 I measured it today using projectized jEdit41 (about 340 files)
from the CVS repository and the time still less than 1 minute.
1.3 Maksim's measurements were reported in the window starting 06/21/07
and ending today - between the fix for 107599 (that added nodes
recalculation after RE - that happened to take 6 minutes) and
the fix for 108893 that fixed these 6 minutes.
>- generating class diagram takes about 45 seconds
2.1 creating diagram for all (~500) elements in REd JEdit project
(ie. expand _all_ folders) took 66 sec.
2.2. creating diagram for all elements
under org.gjt.sp.jedit.gui (50 elements) took 6 sec.
>- multi selection of nodes from UML project takes 5-10 seconds
3.1 selecting all, ~500 elements, ie. when _all_ folders
expanded, in jEdit REd UML project took about 6-7 sec.
3.2 selecting all nodes under jEdit src Java Project project,
ie. when _all_ folders expanded, took about the same 6-7 sec.
3.3 selecting 50 nodes as in 2.2 took no noticeable time
>- popup is also slower than 100 ms for sure
4.1 popup on selected all, ~500 elements, ie. when _all_ folders
expanded, in jEdit REd UML project took about 1-2 sec.
4.2 popup on selected all nodes under jEdit src Java Project project,
ie. when _all_ folders expanded, took about the same 1-2 sec.
4.3 popup on selected 50 nodes as in 2.2 took no noticeable time,
though very possibly that it was longer than 100ms. Without precise
automated measurements it is impossible to report any differenece here
from the popup in similar conditions in Java Project
4.4 calling popup on _all_ nodes a couple of times i was "unlucky"
to have to wait for several minutes before i decided to kill the IDE.
Stack trace (attached) showed that it was kicking in of
JavaRefactoringGlobalAction.enable(). See following lines in
>- slow startup time with UML pack
5.1 at first startup UML copies a lot of data into userdir.
Reported separately as IZ 103638.
5.2 not-first startups. As i reported before on the nb-perf,
adding or removing UML doesn't have stopwatch-noticeable effect.
Results of more presize, programmatic, measurements are already
reported as IZ 81233, IZ 81266
>- huge amount of data in userdir - without touching any UML functionality
>... on my notebook (TM 8104 / Intel PM 2GHz 1GB).
Thus i don't see any new items of P1-P2 level (that would warranted
working on them in the current period of P2 bug fixing), except
may be the item 2.1 that was in our plans for quite a bit of time.
Created attachment 44726 [details]
refactoring action enable()
Created attachment 44727 [details]
refactoring action enable()
the hardware i used for measurements described
in the comments dated "Thu Jul 5 04:47:09" above
is notebook 2.33GHz, 2Gb RAM
the occasional hang by JavaRefactoringGlobalAction.enable() of already opened popup
was reported as IZ 108994
NB 6.0 is released.