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.
The time to show popup menu in component inspector exceeds expected limits on all supported platforms. Results on JFrame20kB from core/test/qa-performance/src/gui/data/ and its JFrame node for Linux/Solaris/WinXP on machines with recommended hw (+ comparision to NB3.5.1). J2SDK1.4.2_03, 200402171900 build: 237 ms (+76.6%) 248 ms (+8.7%) 458 ms (+258.1%) Also all WinXP results show significantly worse values than in NB3.5.1. They vary between 160 and 300 ms though NB3.5.1 is under 100 ms.
My own measuring on Win2000 jdk1.4.2_01 PIII 733 MHz (ms): Current dev 200402221900: 1st invocation: 609 2nd invocation: 172 NB 3.5.1 1st invocation: 312 2nd invocation: 78
The performance problems has two main causes: 1) the whole palette content is read and scanned for the "Layout" submenu; this shows mainly on the first popup menu invocation. 2) PasteAction does number of various updates, touching the clipboard etc. This shows both during the first and subsequent menu invocations - and seems to be responsible for the most of the time regression. I've fixed the form editor part. The first invocation time dropped by cca 200ms. /cvs/form/src/org/netbeans/modules/form/actions/SelectLayoutAction.java new revision: 1.29; previous revision: 1.28
Passing to openide for evaluation of what the PasteAction presenter is doing when the popup menu is created. Note that by removing the PasteAction from the form editors' nodes, the invocation time falls down to 125/61 ms. Attaching an HTML exported profiler snapshot showing the calls related to the PasteAction.
Choosing "actions' component though also explorer or nodes might be responsible...
Created attachment 13602 [details] profiler snapshot exported
Did you have something in clipboard when the action was performed? This can be related to an already reported problem.
Looks like if there is something from the IDE in the clipboard, everything is much faster. Otherwise the times are as reported.
this is likely related to issue 38441. Clipboard.getContents is slow. I had a hack which bypasses calling system clipboard completely. The hack is enabled only on Unix bcs I thought the call is slow on those platforms only. Will enable it on windows as well, then Tomas can remeasure to see if it helps this issue
Tomas, I just fixed issue 38441. Can you please check if it helps this issue
Confirming, it helps. The times are now 172ms (1st) and 78ms (2nd). So you can close this issue as fixed.
okay, i close it. Radim please watch the perf test results tomorrow
Results form last builds compared to 3.5.1 shows improvement after Tomas' fix although there is higher variance than I would like to see. Thanks Tomas. Win2K Linux Solaris WinXP Feb-22 N/A 178 ms (+43.8%) 281 ms (+8.9%) 213 ms (+84.9%) Feb-24 N/A 91 ms (-26.5%) 198 ms (-23.1%) 125 ms (+8.0%) Feb-25 73 ms (-41.6%) 101 ms (-18.4%) 126 ms (-51.3%) 141 ms (+22.2%)