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.
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.
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
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
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.
Created attachment 8018 [details] profiling snapshot of first context menu invocation on java node
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.
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.
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
Created attachment 8027 [details] profiling snapshot after simple optimization (see AWT-EventQueue thread only)
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
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!
Fixed 1st part, added warm-up task for context menu. core/ui/../ContextMenuWarmUpTask.java 1.1 /resources/layer.xml 1.37
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).
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.
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...
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.
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.
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.
As Tomas suggested I created separate issue for ToolAction (issue #30676) and thus closing this one.