[PP]nsWebShellWindow::LoadMenus() takes 60% of the time on New Window

VERIFIED FIXED in M10

Status

defect
P3
normal
VERIFIED FIXED
20 years ago
Last year

People

(Reporter: pierre, Assigned: saari)

Tracking

Trunk
PowerPC
Mac System 8.5

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

I profiled the "New Browser Window" command of AppRunner on the Mac using a
recent build. It appears that 60% of the CPU time is spent in a single call to
nsWebShellWindow::LoadMenus().

I'm setting the Component to RDF because down the stack almost all the time is
spent in XUL and RDF functions.

I'll try to attach a screen snapshot of my Profiler window because it wasn't easy
to Capture: I had to set the number of functions to 32000 in ProfilerInit() which
caused the profiling to take around 20 minutes + 15 minutes to open the output
file.
Blocks: 7251
I attached the screen snapshot of the profile. The first column of the left is
the number of times the function is called. The last column of the right is the
percentage of CPU time spent in this function and its children.
Something must be wrong. I disabled nsWebShellWindow::LoadMenus() and it still
takes about 40 seconds to open a new window. I guess something went wrong with
the Profiler. Maybe it really overflowed and captured only a small of the whole
process.

Feel free to close as Invalid. I'm not doing it because you still might want to
have a look and take a profile on another platform.
Marked assigned. Hey dp -- you might want to look at this while you're
profiling app startup on Win32. Hyatt, might this be the GetPrimaryFrameFor()
problem?
Marked assigned. Hey dp -- you might want to look at this while you're
profiling app startup on Win32. Hyatt, might this be the GetPrimaryFrameFor()
problem?
Assignee: waterson → saari
Status: ASSIGNED → NEW
Naw, this is just a mac-specific bug.  Mac has to build all its menus up front,
which means it is opening and descending into all of the RDF menus.  This is
scheduled to be fixed in M9.

This bug is basically a duplicate of a bug saari already has filed against him,
namely that MAc menus need to be dynamic.

It is true that GetPrimaryFrameFor() is slowing down the startup a bit, but that
should be negligible on any platform other than the Mac.  And it's only coming
into play on the Mac because the document is much larger than it is on WIndows or
GTK (since all the content node menu items are getting built).
Summary: nsWebShellWindow::LoadMenus() takes 60% of the time on New Window → [PP]nsWebShellWindow::LoadMenus() takes 60% of the time on New Window
Target Milestone: M8 → M9
Not fixing until M9, retargeting.
Status: NEW → ASSIGNED
Target Milestone: M9 → M10
Dependent on Mac dynamic menus, which got punted to M10.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Mac dynamic menus are checked in, startup time should no longer be hindered by
them. Marking fixed
QA Contact: phillip → tever
QA Contact massive update.
verified: Mac 2000012601
Status: RESOLVED → VERIFIED
No longer blocks: 7251
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.