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.
Tomorrow I will attempt to demo UML support at NetBeans Day Seattle. To do this I will use a reverse-engineered diagram of the Wizard project - http://wizard.dev.java.net I can probably talk over it, but there are definite performance problems when multi-selecting Java class objects in the UML project to generate a diagram - with each additional selection there is a greater delay during which the UI is unresponsive. With only six nodes selected, selecting the sixth took several seconds. What is happening inside NetBeans when this is going on is: - Action enablement is being recomputed based on the merged Lookup of all selected nodes - The property sheet is creating an intersection of the properties common to all selected nodes Closing the property sheet did not make a noticable difference, so I'm guessing the expensive thing is action updating or something similar. That sort of thing is usually pretty simple to optimize - there is probably work happening that doesn't need to be done here.
I can reproduce with 6 classes on newly created project, but sometimes selection of 6th class take seconds and selection of 7th class takes a moment. All selected elemnts should be of the same type (in my case). Issue can be workarounded by selection of at least one package.
UML had to use some bridge code to integrate Embarcadero's property framework with NB's, which causes some performance overhead.
The problem isn't specific to the UML module. Once opened the property sheet continues to listen to the selected node set changes and request property sets accordingly from the nodes even if the Properties window is closed. To feel the difference one would need to start the IDE without Properties window (ie. close Properties window and restart the IDE).
The property sheet should *not* be listening for selected node changes if it is not onscreen. If it is really doing so, please file a bug.
For specific comparative measurements for current 5.5 release please see 75895.
it so happened that previously mentioned measurements of 1.5 sec on 140 nodes were a good case. These 140 nodes were of different type and didn't expose the problem that is exposed when only nodes of the same type are selected. For example, the 74 nodes out of these 140 are class nodes. Selecting only them takes about 11 sec. The problem is that Netbeans Property Sheet machinery queries the nodes for theirs property sets again and again (when nodes are of different types and thus have different prop sets the machinery discovers it and stops doing the queries). The problem is reported as IZ 94321. A patch was also submitted that corrects the problem - specifically it decreases the time in the case mentioned above in about 15 times, ie. from 11 sec. to 0.7 sec. for 74 nodes. Other problem - closed Property Sheet still listens and queries - reported as IZ 94318
*** Issue 75895 has been marked as a duplicate of this issue. ***
Fixed a place where we unnecessary parsed the same file multiple times. That resulted in the following improvement: 1. "good" (i.e. not affected by Netbeans bug 94321) case: 142 mixed nodes (74 class nodes, 68 interface) from 1.5 sec to 1.1 sec. 2. "bad" (ie. affected by Netbeans bug 94321) case: 32 nodes of the same type (class nodes) from 4.8 sec. to 3.8 sec. Note: once Netbeans fix the 94321, the "bad" case mentioned above would improve in about 15 times, ie. it would come down from 3.8 sec. to less than 0.3 sec. for above mentioned 32 class nodes. I produced and submitted patch for 94321 so it should not take them long.
verified in build 070213_1. Not sure if fix to issue 94321 is already in the The performance has been in NB but the selection seems to be no issue now.
*** Issue 80948 has been marked as a duplicate of this issue. ***
*** Issue 82889 has been marked as a duplicate of this issue. ***