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.
dev#200111230645 jdk1.4.0-rc1-b87 When opening popup menu in the editor over some file from cvs filesystem it is longer than over ordinary file from local fs. On my Solaris it is cca 5x longer. What's happenning? Can somebody investigate this? Note this isn't new isse, it's only performance problem, but now it is reported to track root of the problem. Also note this can be observed only first time the popup is invoked after ide start.
I'll try to investigate it.
The problem must be somewhere outside of VCS modules. It takes long also on JavaCVS filesystems although we handle the FS actions in a very different way. I've put some messages around VcsFileSystem.getActions() and found out, that it takes quite long time before somebody calls the getActions(). Thus I thing it's not VCS issue.
OK, my findings so far are following: During the popup menu generation, few millis are spent on each item added, like: added null in 0ms added org.openide.actions.CutAction in 3ms added org.openide.actions.CopyAction in 3ms added org.openide.actions.PasteAction in 3ms added null in 0ms added org.openide.actions.DeleteAction in 3ms added null in 0ms added org.openide.actions.NewAction in 4ms added null in 0ms added org.openide.actions.ToolsAction in 6ms This is about the same for non-VCS and VCS files. The difference is in the time spent adding TCaction (a combo of actions bound to a TC), where adding the combo takes much more time on VCS files, in means of ~120ms vs. ~20ms I've then checked the adding of the combo and most of the time is spent on FSAction, eg: Adding subactions: added org.openide.actions.SaveAction@6af790 in 2ms added org.openide.actions.CloneViewAction@5753b7 in 3ms added null in 0ms added org.openide.actions.CloseViewAction@6b717e in 3ms added null in 1ms added org.openide.actions.FileSystemAction@200db9 in 117ms I'll try to continue tomorrow. Maybe there is a problem of checking all subactions of the FSAction submenu and it should be faster (see 6ms of ToolsAction).
The actual problem is clear: The (org.netbeans.modules.vcscore.)VcsAction, whenever asked for a presenter, builds the whole submenu of all the available VCS actions. We had the same problem with tools action. You should rewrite the menu presenter genetration to return noninicialized submenu that will be filled-in as soon as a user try to expand that submenu.
You're right, this would speed up the menu creation. But I still don't think, that this is the root cause of the problem, since: - The opening of the menu does not take so long in the Explorer, - In the Editor it takes long only the first time. But the menu is reconstructed each time. It's not P2 IMHO. Happens only the very first time the menu is invoked. I will think about rewriting of the menu creation to 3.3.1
That's in the point of view. I don't talk about the first usage after the start, I don't even talk about the first usage on a particular file. I talk about the context menu being slower on VCS files than of local files both in the explorer and the editor. Of course the menu takes longer time in the editor than in the explorer. The problem is that each menuitem in the menu takes few millis to complete (except completion related items that take few tens of millis), even the tools menuitem take about 6ms, but the FS item on VCS fs takes about 100ms, which is itself more than the _whole_ menu creation should take (although we're still far from pushing the whole creation below 50ms) I agree with P3
I'll take a look at it.
Started to work on it...
Fixed in dev and release33 builds. The menu is constructed lazily. It should be faster, but I didn't measure the performance gain.
Great, it is at few milliseconds now. Thanks
Resolved for 3.4.x or earlier, no new info since then -> closing.