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 189036 - One call from EditorRegistry.fireEvents generates 187 MainMenuAction$1.propertyChange
Summary: One call from EditorRegistry.fireEvents generates 187 MainMenuAction$1.proper...
Status: RESOLVED WONTFIX
Alias: None
Product: editor
Classification: Unclassified
Component: Actions/Menu/Toolbar (show other bugs)
Version: 6.x
Hardware: All All
: P3 normal with 1 vote (vote)
Assignee: Miloslav Metelka
URL:
Keywords: PERFORMANCE
: 212094 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-07-28 21:43 UTC by Jesse Glick
Modified: 2016-07-07 07:31 UTC (History)
19 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter: 168922

Attachments
nps snapshot (9.62 KB, application/nps)
2010-07-28 21:43 UTC, Jesse Glick 		Details
nps snapshot (22.11 KB, application/nps)
2010-10-19 01:02 UTC, dwuysan 		Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2010-07-28 21:43:03 UTC 
Build: NetBeans IDE Dev (Build 100728-e3e2641f491e)
VM: Java HotSpot(TM) Client VM, 17.0-b16, Java(TM) SE Runtime Environment, 1.6.0_21-b06
OS: Linux

User Comments:
jglick: Closed a diff window.



Maximum slowness yet reported was 15364 ms, average is 7236
Comment 1 Jesse Glick 2010-07-28 21:43:14 UTC 
Created attachment 101071 [details]
nps snapshot
Comment 2 David Strupl 2010-09-18 19:16:59 UTC 
Passing to the platform team for evaluation.

The following pseudo call:

a = org.openide.util.Utilities.actionsGlobalContext().lookupResult(ActionMap.class);
a.allInstances()

takes sometimes a way too long. We call it from AWT EDT - if it is not the correct way please suggest how we should get the context for the menu ... Thanks a lot for your help.
Comment 3 Jaroslav Tulach 2010-09-27 20:35:08 UTC 
Rewrite org.netbeans.modules.editor.MainMenuAction$1.propertyChange() to not do batch updates of 200 elements(?) in AWT thread.
Comment 4 dwuysan 2010-10-19 01:02:09 UTC 
Created attachment 102465 [details]
nps snapshot

Closing all tabs
Comment 5 David Strupl 2012-11-15 09:22:33 UTC 
I apologize but I don't understand your comment. Looking at some new snapshot, e.g. 628848 it still seems that my comment 2 holds. Couple of calls to org.openide.util.Utilities.actionsGlobalContext().lookupResult(ActionMap.class); take several seconds.

Maybe I just misunderstood your comment. Can you please point me to the code that does the batch update? Thanks a lot.
Comment 6 Jaroslav Tulach 2012-11-26 15:47:17 UTC 
1 call from org.netbeans.api.editor.EditorRegistry.fireEvents()	
spread to 187 calls to 
org.netbeans.modules.editor.MainMenuAction$1.propertyChange()	

Should you split the calls to 187 invokeLater(runnable), the EDT will be occupied only for 100ms each time.
Comment 7 Egor Ushakov 2013-04-24 15:00:33 UTC 
it looks like this affects c++ navigator mostly
Comment 8 Svata Dedic 2013-07-17 07:30:08 UTC 
*** Bug 212094 has been marked as a duplicate of this bug. ***
Comment 9 Svata Dedic 2013-07-17 14:27:12 UTC 
(In reply to comment #6)
> 
> Should you split the calls to 187 invokeLater(runnable), the EDT will be
> occupied only for 100ms each time.

This is true, but AFAIK mouse events have the same priority as invokeLater() events and painting has the priority even lower. If the work is just divided into invokeLaters, then the EQ will pile up with invocation events and painting/input stops anyway ?
Comment 10 Martin Balin 2016-07-07 07:31:40 UTC 
This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue.

Thanks for your cooperation,
NetBeans IDE 8.2 Release Boss