Closed Bug 49142 Opened 24 years ago Closed 18 years ago

Mac menus are slow (Bookmarks, Folders)

Categories

(Core :: XUL, defect, P3)

Product:
Core
Component:
XUL
Platform:
PowerPC
Mac System 8.5
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX
Milestone:
Future

People

(Reporter: sfraser_bugs, Unassigned)

References

Details

(Keywords: perf, Whiteboard: [nsbeta3-])

Attachments

(1 file)

under certain cases, prevent RDF graph notifications
1.45 KB, patch
mikepinkerton
: review+
Details | Diff | Splinter Review 
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.
Keywords: nsbeta3, nsmac2, perf
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)
Whiteboard: [nsbeta3+]
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.
Blocks: 91351
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
Blocks: 7251
Status: NEW → ASSIGNED
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+
nice. sr=sfraser

very nice!
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.
Keywords: nsbeta3
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".
OS: Mac System 8.5 → MacOS X
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: 18 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.

Attachment

General

Creator:
Created:
Updated:
Size: