63731 - font prefs panel is slow (nsMenuFrame::GetPrefSize)

Status: NEW

(Core :: XUL, defect)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

DESCRIPTION:  I was investigating why the fonts pref panel loads so slowly, and
I found (with jprof) that a lot of the time was being spent in nsMenuFrame
reflow methods -- slightly over half the time loading the font prefs panel was
within nsMenuFrame::GetPrefSize.  So, I created a testcase of a very large menu,
and the profile was similar (except about 4/5 of the time was within
nsMenuFrame::GetPrefSize).  This testcase also takes rather a long time to load,
although it seems to be O(N) in the number of menuitems.

FWIW, the same testcase with the equivalent HTML seemed to take about the same
amount of time.  Maybe I just have too many fonts...

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: tar.gz file containing 2 profiles and XUL and HTML testcases

Comment 2

[Peter Trudelle]

->pinkerton

Comment 3

[Mike Pinkerton (not reading bugmail)]

cool, thanks for the profiles. I'll check this out. cc'ing hyatt too.

Comment 4

[Blake Ross]

I was looking at this with dbaron earlier.  It's probably insignificant, since 
it's not a big deal in the profiles, but the fonts (js) code contains a 
ridiculously high number of getElementsByAttribute() calls in nested loops, 
which should be fairly expensive.

Comment 5

[Blake Ross]

Some of the biggest offenders:

nsCSSFrameConstructor::ContentInserted
nsCSSFrameConstructor::ConstructFrame
nsCSSFrameConstructor::ConstructXULFrame
nsCSSFrameConstructor::ProcessChildren
nsXULDocument::AttributeChanged
nsXULElement::SetAttribute
nsMenuFrame::GetPrefSize
nsMenuFrame::MarkAsGenerated

Comment 6

[Blake Ross]

--> me to look into what can be done on the xpapps side of things...

Comment 7

[Peter Trudelle]

Mass moving lower-priority bugs to 0.9.6 (with Blake's pre-consent) to make room
for remaining 0.9.4/eMojo bugs and MachV planning, performance and feature work.
 If anyone disagrees with the new target, please let me know.

Comment 8

[David Hyatt]

This is an interesting bug.  The menu lists are actually having to build their
subcontent because the flexibility check is busted in nsMenuFrame.  It doesn't
take grids into account (in the case of grid, the flex is applied from the
column, and since the code doesn't check for that, it thinks the menulists are
inflexible and therefore need to intrinsically size).

Comment 9

[sairuh (rarely reading bugmail)]

would this be affected by [dependent on?] bug 26670? just curious...

Comment 10

[sairuh (rarely reading bugmail)]

*** Bug 115828 has been marked as a duplicate of this bug. ***

Comment 11

[Patty Mac]

Seen on Mac os 10.1 (commercial build: 2002-01-18-08-trunk), one of the color
preferences panel loads so slowly while clicking to different panels like Themes
or history. It sometimes takes forever-- this needs to be fixed.

Comment 12

[sairuh (rarely reading bugmail)]

what patty meant to say is that there's a long wait when switching btwn colors
-> themes or colors -> history. oddly, i cannot repro this on a G3 running mac
os 10.1.2, using today's mozilla bits. hmm.

Comment 13

[Blake Ross]

-> default owner