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 27769 - Bring up context menu on a data object quickly
Summary: Bring up context menu on a data object quickly
Status: RESOLVED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Window System (show other bugs)
Version: 3.x
Hardware: All All
: P2 blocker (vote)
Assignee: Tomas Pavek
URL: http://performance.netbeans.org/respo...
Keywords: PERFORMANCE, UI
Depends on:
Blocks: 26581 29837
  Show dependency tree
 
Reported: 2002-10-03 14:47 UTC by _ rkubacki
Modified: 2008-12-23 13:41 UTC (History)
3 users (show)

See Also:
Issue Type: TASK
Exception Reporter:


Attachments
profiling snapshot of first context menu invocation on java node (37.56 KB, application/octet-stream)
2002-11-22 09:28 UTC, Tomas Pavek
Details
profiling snapshot after simple optimization (see AWT-EventQueue thread only) (26.03 KB, application/octet-stream)
2002-11-22 14:11 UTC, Tomas Pavek
Details

Note You need to log in before you can comment on or make changes to this bug.
Description _ rkubacki 2002-10-03 14:47:23 UTC
Beginning of action: Right-click or press F10 (for
the first time this session)
Initial Feedback: Context menu appears (populated
or unpopulated)
Maximum time allowed: 100 ms
Completion: Context menu fully populated
Maximum time allowed: 1000 ms
All subsequent invokations of the same menu must
complete in 100 ms.
Comment 1 David Simonek 2002-11-19 14:15:05 UTC
Dafe's measurements - testing conditions: PC Dell Pentium III, 600Mhz,
512 MB memory, JDK 1.4.1, Netbeans Main trunk build, mounted sampledir
local filesystem, opened 8 java source files, 3 plain text files.
times in milliseconds, first number shows first invocation, followed
by subsequent invocations.
context menu on folder: 891, 78, 62, 79, 63
context menu on java source: 437, 79, 78, 78
Comment 2 Marian Mirilovic 2002-11-21 16:39:14 UTC
Marian's measurement (time in milliseconds):
conditions: 
 - SUN UltraSparc60 / 512 MB RAM / Solaris 5.8 / CDE
 - JDK1.4.1(01)
 - [nb_dev](200211140100) , MDI
	- mounted sampledir

bring popup menu on nodes by mouse:
 Filesystems node        815     57      51
 Local FS node           810     69      77
 folder                  902     47      78
 java node(selected)     461     75      27
 java node(unselected)   573     91      167
 txt node                251     59      64

Filesystems popup menu are mesaured by QA test infrastructure on daily
builds.

Test cases are described on page :
http://performance.netbeans.org/qa/TestSuites.html#popup_on_local_filesystem_node


	
Comment 3 Tomas Pavek 2002-11-22 09:23:22 UTC
Some investigation of this issue...

There are two things that should be analyzed and optimized:
- the first use initialization (first menu invocation),
- the painting of the menu.

I've looked at the initialization part that slows down the first use
of context menu. ColorPreview java node was used as example. See the
profiling snapshot of invoking context menu on this node for the first
time.

Comment 4 Tomas Pavek 2002-11-22 09:28:05 UTC
Created attachment 8018 [details]
profiling snapshot of first context menu invocation on java node
Comment 5 Tomas Pavek 2002-11-22 09:44:19 UTC
1. The biggest portion of time is spent in
ModuleActions.createActions() - over 40%.

2. Another big part of time takes getting JavaDataLoader actions and
creating their popup menu presenters.

3. When the menu is showing, each action is asked if it is enabled.
This is mainly problem for ToolsAction which asks its subactions if
some of them is enabled, first taking I18nGroupPopupAction which
causes big part of i18n stuff gets initialized.
Comment 6 Tomas Pavek 2002-11-22 09:52:32 UTC
Tried some improvements...

ad 1+2) The warm-up technique could be used for creating the actions
and prepearing menu UI classes.

  ModuleActions.getDefault().getContextActions();
  new org.openide.awt.JPopupMenuPlus();
  new org.openide.awt.JInlineMenu();
  new javax.swing.JMenuItem();

  DataLoader.getLoader(JavaDataLoader.class).getActions();


ad 3) Significant improvement would be to let ToolsAction.isEnabled
return true and not ask (initialize) its subactions. It is enabled
always anyway (haven't seen disabled Tools in popup menu yet), and if
it does not make sense on some node, it should not be there at all.


Using these simple optimizations I get first popup menu invocation
from 469 ms to 188 ms on my machine. So probably worth trying.
Comment 7 Tomas Pavek 2002-11-22 10:07:23 UTC
What else to be improved...

FileSystemAction.getPopupPresenter() is rather expensive (taking about
10% of the remaining time) - but there's nothing in the final popup
menu from this action, so this is wasted time...

NewAction calls getNewTypes causing lots of initialization which seems
to be a bit early (haven't examined why).

Whole explorer seems to be painted when the menu is invoked, not just
the menu itself. This seems to be unnecessary.

To ivestigate further:
  things done by o.o.awt.Actions.SubMenu.addNotify()
  the call stack from MenuSelectionManager.setSelectedPath
Comment 8 Tomas Pavek 2002-11-22 14:11:08 UTC
Created attachment 8027 [details]
profiling snapshot after simple optimization (see AWT-EventQueue thread only)
Comment 9 _ rkubacki 2002-11-25 15:33:29 UTC
Radim's measurement:
PIII/800MHz, Linux (2.4.17), 512MB
NetBeans IDE Dev (Build 200211180100)
JDK 1.4.1-b21

mounted sample dir and openide/src directory

First and subsequent invocations:
1498, 180, 92, 98
1218, 120, 77, 50

Comment 10 David Simonek 2003-01-23 14:32:31 UTC
Peter, please, take care of implementation of this task. In first
round, I think improvements already tested by Tomas Pavek should be
integrated, because they bring significant improvement.
Warm-up technique is described in
http://performance.netbeans.org/responsiveness/improving/preinit.html
Should you have any question, please contact Tomas Pavek, because I'm
on my holiday next week. Thx!
Comment 11 Peter Zavadsky 2003-01-27 14:55:32 UTC
Fixed 1st part, added warm-up task for context menu.

core/ui/../ContextMenuWarmUpTask.java 1.1
          /resources/layer.xml 1.37
Comment 12 Peter Zavadsky 2003-01-27 15:19:41 UTC
With ToolsAction it is not as described.

The action itself is alway enabled.

Problem is that it popup presenter is JInlineMenu, and it needs to
figure out, whether there is at least one enabled 'tools subaction',
if yes the ToolsAction is shown, if not, the ToolsAction is hidden
(therefore it is there JInlineMenu)

All the above seems to be designed that way, so it is not possible to
simply don't ask for that (it would cause bug).
Comment 13 Peter Zavadsky 2003-01-28 12:15:47 UTC
Tomas, let me know what else I'm supposed to do with this, sincd the
ToolsAction problem isn't so straghtforward, and should be solved as
separate issue.
Comment 14 Tomas Pavek 2003-01-28 16:32:50 UTC
I've checked today build (dev 20030128) and the effect is visible. The
first menu invocation takes around 250ms (comparing to yesterday
450ms). Also see issue 27771 and issue 30277.


As for the ToolsAction... Please create a separate issue if it is not
suitable to be solved under this one.

The problem is in that ToolsAction.G.isPopupEnabled(..) which is
called from JInlineMenu goes through all the subactions until it finds
something enabled.

I cannot decide if this method can return always true - it would cause
empty Tools menu appear on some nodes. But it would be performance
improvement, currently seen mainly in issue 30277. The effect on java
node is rather small now, as there appears "Apply patch" action to be
the first now (instead of "Internationalization" which was much more
heavyweight to initialize). But the fact that performance of all
context menus depends on what actions are under "Tools" item (which
may not appear after all) and how behave in isEnabled() method, is IMO
not nice...
Comment 15 Peter Zavadsky 2003-01-30 08:44:45 UTC
I understand it is a performance problem. But I wonder we could change
it your suggested way, try it out, and when you see Tools with empty
(on Filesystems), it is just very ugly. We cannot just remove the
ToolsAction from Filesystem node, cause, if you add e.g. apisupport
module, there appeares some action (Bean browse.. or something like that).

Well maybe it is worth to measure which tools sub action takes longer
time to decide whether they are enabled. Probably such actions should
just check the node type (cookie) and that should be fast, shouldn't it?
... Just thinking about it.

Comment 16 _ rkubacki 2003-01-30 09:17:57 UTC
Would it be possible to show Tools action always when context menu
that contains it is invoked and show its submenu as a non-selectable
item like 'Empty' visualy designated to be only placeholder? What are
the cases when it is actually empty? Of course it is only an idea.
Comment 17 Peter Zavadsky 2003-01-30 11:27:52 UTC
Radim, be aware about how Tools action is designed.

(note we are talking about popup version of Tools action)

It is present almost in every context memu. (It is just no visible,
JInlineMenu can do that).

All subactions are present in that popup menu if they are enabled
(e.g. for certain node), if such sub-actino isn't enabled it is not
present (i.e. not disabled, but not present menu item in the popup),
in case there is no enabled subaction the tools action isn't seen in
the popup (there is menu item, but not visible -> JInlineMenu).

So guess, you now got the clue, how it works, so it is more clear the
problem. The Tools action is just designed that way that is has to ask
its sub-actions whether they are enabled, since the menu item
visibility depends on it.
Comment 18 Peter Zavadsky 2003-02-05 08:31:49 UTC
As Tomas suggested I created separate issue for ToolAction (issue
#30676) and thus closing this one.