Closed Bug 49142 Opened 20 years ago Closed 13 years ago
Mac menus are slow (Bookmarks, Folders)
Menu sluggishness came up as a UI responsiveness issue, and it was noted that Mac menus rebuild their contents from the DOM every time you click on them, in contrast to XP menus which deal more efficiently with content changes.
Isn't this mainly just the bookmarks menu (and for some folks, menus that contain a folder hierarchy)? I've got a machine that doesn't even qualify as an N6 target (its a 9600/300), yet all other menus seem snappy to me.
It is just large bookmarks menus that seem slow to me. It will still be slow the first time you bring it up, even if I don't rebuild every time. Iterating that much content is slow :-( What I want to know is, do you want me to focus on making the menu construction faster, or just construct once if possible? (yeah, I know we want both, which first?)
Status: NEW → ASSIGNED
I suspect that using a cached copy would be easier than making construction faster, and would be good enough for all but the first access. Of course, if you can make construction fast enough, who cares if it happens every time? Speaking as owner of one of the larger bookmarks menus around, I'd much rather eliminate nearly all of the delay N-1 times rather than eliminate only some of the delay N times. Of course, if it continues to make me wonder if it crashed, I'm still gonna use bookmarks in the sidebar. nsbeta3+, P3 for M18
Summary: Mac menus are slow → Mac menus are slow (Bookmarks, Folders)
Target Milestone: --- → M18
Profile data from window activation shows that nsMenu::HelpMenuConstruct() takes 10% of the time spent in handling the activate event (the rest being mainly in focussing the text widget, and updating commands). This 10% seems high. It breaks down thus: nsMenu::HelpMenuConstruct() 1 call 10.2% nsMenu::OnCreate() 1 5.7 nsMenu::LoadMenuItem() 2 2.3 nsXULElement::SetAttribute() 1 2.0 nsMenu::OnCreate spends most of its time in nsXULElement::HandleDOMEvent. nsMenu::LoadMenuItem spends most of its time in nsMenuItem::SetChecked which in turn calls nsXULElement::SetAttribute.
I blame saari for the help menu code ;) ;) cc'ing him.
Simon, thanks for the numbers. I think that I can only build the Help menu once if we start cacheing built menus and listening for updates instead of tearing down and rebuilding every time. As for making the build of it faster, I don't have too many ideas, that code is pretty straight forward DOM iteration and manipulation.
Okay, I just checked in the mac menu caching, so the first time you bring up bookmarks will be slow, but after that it should be fast. Should this still be beta3+ for the slow initial construction time?
This is about as good as we can afford to make it for 6.0, nsbeta3-/future.
Whiteboard: [nsbeta3+] → [nsbeta3-]
Target Milestone: M18 → Future
let's revisit this bug, and get it on the performance hot list.
I'm not going to be able to address this in 0.9.4, it just isn't that high on my priority list, especially considering that the construction is still straight forward DOM iteration, attribute getting/setting and style resolution. Make those faster and this gets faster too.
The bookmarks menu is espeicially slow to build on Mac OS X -- you get the rainbow cursor for a few seconds. Can we drag this back from the future?
sometimes this is fast, sometimes it is slow. i don't always get the rainbow death-wheel with the same profile on the same machine with the same build. i suspect the carbon menu code might burp at times. i'll investigate some, but not sure what else we can do here.
It's slow the first time you hit the bookmarks menu in a session, and much slower than on Mac OS 9 in this regard.
reassign from saari to rjc. :-)
Assignee: saari → rjc
Status: ASSIGNED → NEW
Here's the problem: as bookmarks are read in and RDF nodes are created and asserted into the bookmark datasources inMemoryDataSource, each addition of a RDF node fires a notification to each/every observer (such as the Mac menu widgetry). This isn't (relatively) much overhead, but once the XUL template gets involved, the associated "cost" increases dramatically. If you can work around that, you can cut a lot of time (including out of startup, if data was being processed then): [Note: Mac OS 10.1 on my G3 Pismo Powerbook (1 gig RAM, 32 MB IDE drive - 5400 RPM)] Startup/first menu trip *before* patch: Bookmark processing: 9,687 microseconds Favorites processing: 618,925 microseconds <-- ouch!! Startup/first menu trip *before* patch: Bookmark processing: 9,669 microseconds Favorites processing: 49,843 microseconds <-- nice!! Nice, heh? Saves about 1/2 second on startup for me.
Who wants to cut their Mac Mozilla startup time by 1/2 second or so? :) Just try out this (Mac) patch. It needs r/sr too. :) [Shame I don't have CVS access yet... guess I should try and get that soon.]
Oops... in my timing data, the second case is of course *after* the patch is applied. :)
welcome back rjc, cool patch! however, it doesn't address the responsiveness issue which this bug was mainly filed for. I guess what's next is to tackle the time to create the bookmarks menu when you click on it in the menubar. If you land this patch (as you should), can you keep this open and look at that next? are there any other roots which could benefit from batching updates?
Comment on attachment 54179 [details] [diff] [review] under certain cases, prevent RDF graph notifications r=pink
Attachment #54179 - Flags: review+
Do menus (in Mozilla under Mac OS X 10.1) still feel unresponsive *AFTER* this patch [which only affects first-time bookmarks]? They feel as fast as any other native app to me. Opinions? [Please give specific cases which do not.]
I've got a big bookmark file (2300 URLs + 100 folders, roughly) and using that, I see the "rainbow death wheel" on Mac OS X the first time I bring up the bookmark menu. I'm in the process of cooking up some improvements to RDF which at the moment give me a 20-30% speedup on reading in and processing the big bookmark file. I don't have data on XUL template interactions yet, although I expect at least some small percentage improvement. With the changes, I no longer ever see the "rainbow wheel o' death" with the bookmarks menu; however, the bookmark menu is still sluggish to appear the very first time. It feels like the Mac code is being really eager and building up all sub-menus as well. If we could defer populating sub-menus until they are about to appear, that would be a nice improvement. I know I could do it in a custom MDEF (I've written more than one in my life), but those old days are gone. Possible in the current Mac world? saari/pink ?
The sort service cleanup in bug 105783 should give a good speedup to building the menu the first time across all platforms, including Mac (though I guess there may be something platform-specific going on here as well). What I have at the moment is cutting time to build a 1000-element bookmark menu by 60-70%, including a 10x speedup in the container insertions. Since this is purely in changes to the XULSortService, it should stack with whatever RDF magic rjc is up to.
Depends on: 105783
The menus should not building submenus agressively, they didn't in the OS 9 code anyway, they're doing it on the fly as requested. If they are building ahead, it is a bug.
saari: It was just a guess, I could be wrong. :) It would be good to verify, though. The real reason why it feels overly-aggressive to me is that, on my Mac OS X build, I see IE Favorites being read in during startup. That code was factored a long time ago so that they wouldn't be read in until something specifically was asking for info on them via RDF... which smells like the code which builds up the menus.
we shouldn't be building all the submenus. or at least, we shouldn't be populating them. if we are, that's a heinous bug. we already have custom carbon events that build the submenu when told. i'm pretty sure they're working....
rjc: interesting. Go forth and investigate. I don't know why the IE favorites would be getting pulled in now.
Not only Mac OS 8.5... I am using OS 9.2.2 and the menus are also slow on 9.x.
This bug is targeted at a Mac classic platform/OS, which is no longer supported by mozilla.org. Please re-target it to another platform/OS if this bug applies there as well or resolve this bug. I will resolve this bug as WONTFIX in four weeks if no action has been taken. To filter this and similar messages out, please filter for "mac_cla_reorg".
Assignee: mozilla → nobody
Status: ASSIGNED → NEW
QA Contact: jrgmorrison → xptoolkit.menus
This was filed against old versions of Mac OS and is no issue on Mac OS X anymore - I just put slightly over 1000 bookmarks "under" the bookmarks button and it it took <10s on first opening and <2 on subsequent openings. Reverting Simon's OS change to the original setting and closing as WONTFIX, since we don't support these old ones.
Status: NEW → RESOLVED
Closed: 13 years ago
OS: Mac OS X 10.2 → Mac System 8.5
Resolution: --- → WONTFIX
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: xptoolkit.menus → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.