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 50552 - Expensive ActionProviders in debugger
Summary: Expensive ActionProviders in debugger
Status: CLOSED FIXED
Alias: None
Product: debugger
Classification: Unclassified
Component: Code (show other bugs)
Version: 4.x
Hardware: PC All
: P3 blocker (vote)
Assignee: Martin Entlicher
URL:
Keywords: PERFORMANCE
Depends on:
Blocks: 49990 70575 70726
  Show dependency tree
 
Reported: 2004-10-18 12:15 UTC by _ rkubacki
Modified: 2010-04-29 09:19 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
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 _ rkubacki 2004-10-18 12:15:18 UTC 
RunToCursorActionProvider is listening to too
many changes - MainProjectManager,
TopComponent.Registry, DebuggerManager. This means
it updates its enabled/disabled state every time
when an event arrives including every notification
about TC opening and similar.

This is very similar to JspRunToCursor but
sligthly better because there is no conversion
URL->URI->FileObject so shorter time is spent in
this provider.
Comment 1 _ rkubacki 2004-10-18 12:35:32 UTC 
Seems to be common pattern in debugger. Property changes are re-fired
from EditorContextImpl. During startup there are events for
activated+current nodes, every opened TC, activated TC. All these
changes are propagated to action providers to update their state.
Comment 2 Jan Jancura 2004-10-27 16:19:57 UTC 
The primary problem is in Openide - just do not fire so many changes
during startup. But we can do some improvements, probably.
Comment 3 _ rkubacki 2004-11-26 08:54:06 UTC 
Blaming the openide does not help much. You can file a bug/rfe if you
think that there are avoidable events fired but at least 'tc opened'
is expected by some modules and this is the reason why your approach
does not scale well. Any progress on this?
Comment 4 Martin Entlicher 2005-11-03 15:58:28 UTC 
This is the consequence of the design of debugger actions.
The action state is cached, so that isEnabled() is fast. But in order to work
correctly, one has to "push" the correct state there each time something changes.

If the action's state depends on selected node(s), this is not much efficient,
because the selected nodes are changing often.

isEnabled() delegating to ActionsManager.isEnabled() would have to be added into
org.netbeans.modules.debugger.ui.actions.DebuggerAction.
The problem is, that this would change the behavior and this is API...
Comment 5 Martin Entlicher 2005-11-03 16:02:00 UTC 
The performance team should complain sooner, I will not change the API in this
stage.
Comment 6 Martin Entlicher 2006-03-28 10:45:31 UTC 
Also ToggleBreakpointActionProvider should obtain events only when a current URL
has changed (and not get all node change events). A way how to attach for more
specific events should be added.
Comment 7 Martin Entlicher 2008-10-10 14:26:29 UTC 
This should have been fixed by the new EditorContextDispatcher.
Please correct me if I'm wrong.
Comment 8 Quality Engineering 2010-04-29 09:19:41 UTC 
Verified ... and Closing all issues resolved into NetBeans 6.7 and earlier.