77938 - investigate nsTextFrame::ComputeWordFragmentWidth() implementation

Status: RESOLVED WONTFIX

(Core :: Layout: Text and Fonts, defect, P4)

Description

[Chris Waterson]

Text measurement is a major component of the time (e.g., 1/3) spent laying out
long pages (cf. bug 56854). Although much of it is spent in the toolkit,
nsTextFrame::ComputeWordFragmentWidth() accounts for a significant amount
(typically 1/4) of text measurement time. Analysis done in bug 56854 did not
dive into this method. Logging a task to do so.

Comment 1

[Adam D. Moss]

A lot has happened since April.  Is this still
a big-hitter?

Comment 2

[Chris Waterson]

I'm futuring this bug because I'm not going to get to it before mozilla-1.0.

Comment 3

[Randell Jesup [:jesup] (needinfo me)]

Comments from bug 116437, which is about a 24MB file taking forever to layout.
The jprof is at http://bugzilla.mozilla.org/showattachment.cgi?attach_id=65191
The jprof might be helpful in deciding if this is still an issue.

Typical: 
  Mostly Reflowing lines:

12% direct (90% total) in ReflowDirtyLines()
4% total in nsFontCache::GetMetricsFor()
6% direct in nsBlockReflowState::RecoverStateFrom()
2% direct in nsBlockFrame::PropagateFloaterDamage()
3% total in nsFrame::Invalidate()
10% direct in nsLineBox::GetCombinedArea()
4% direct, 13% total in nsBlockFrame::ComputeFinalSize()
6% direct in nsBlockFrame::BuildFloaterList()
8% total in nsBlockFrame::PlaceLine()
1.5% total in nsCSSRendering::FindBackground
3% total in nsHTMLReflowState::nsHTMLReflowState
5% direct in nsFrameList::LastChild
10% total in nsRenderingContextGTK::GetTextDimensions()

Comment 4

[Simon Montagu :smontagu]

Source file no longer exists.