If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

minefield repeatedly goes unresponsive for multiseconds when loading 7M file. burning cycles in nsTextFrame::EnsureTextRun

RESOLVED WORKSFORME

Status

()

Core
Layout: Text
--
major
RESOLVED WORKSFORME
10 years ago
7 years ago

People

(Reporter: martin, Unassigned)

Tracking

({perf})

Trunk
x86
Windows 2000
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9pre) Gecko/2008042906 Minefield/3.0pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9pre) Gecko/2008042906 Minefield/3.0pre

using minefield apr29 on windows 2000 or ff3b5 on ubuntu hardy, do this URL:
http://ddebs.ubuntu.com/dists/hardy/universe/binary-i386/Packages

On ubuntu the entire windows goes gray as the app is completely unresponsive. On windows, I can't use any menus, I can't click STOP or BACK etc (all TABs in all minefield windows becomes unresponsive).

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
(Reporter)

Comment 1

10 years ago
Created attachment 319608 [details]
I broke into windbg a couple of times and sampled some stacks (zipped log from windbg)

Comment 2

10 years ago
Confirmed on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5) Gecko/2008032620 Firefox/3.0b5 and a more recent nightly.
It took over a minute of loading before it became unresponsive. I'm on 0.5Mbit connection, so perhaps it's something in the code of the page itself at a certain point causing this?
Most of those stacks are textrun construction.  The file is text/plain, so I would have thought bug 386122 would have helped here...

Doing a shark of this right now to see whether that tells me anything useful.
Severity: critical → major
Status: UNCONFIRMED → NEW
Component: General → Layout: Fonts and Text
Ever confirmed: true
Keywords: perf
Product: Firefox → Core
QA Contact: general → layout.fonts-and-text
Version: unspecified → Trunk
Looking bottom-up, Shark says that 10.6% of the time is in TextRunWordCache::MakeTextRun, 9.9% of the time is in nsTextRunWordCache::CacheHasEntry::KeyEquals, 9.6% s in gfxTextRun::CopyGlyphDataFrom, 6.4% is in SearchTable (mostly called from TextRunWordCache::LookupWord), 5.9% in IsWordBoundary, 5.6% in nsTextFrameUtils::TransformTExt, 3.2% in nsLineBox::IndexOf (called from nsBlockInFlowIterator::nsBlockInFlowIterator), 3.1% in BuildTextRunsScanner::BuildTextRunForFrames, 3.1% is IsBoundarySpace, 2.6% in BuildTextRunsScanner::FlushFrames.

Top-down, 61.8% of the time is under nsTextFrame::EnsureTextRun.  Note that I just profiled for 60s somewhere near the beginning of the load; it might well be that this fraction is higher when more of the page is loaded.

still a pig. and UI still mostly unresponsive.
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.7) Gecko/20100713 Firefox/3.6.7 (.NET CLR 3.5.30729)
Summary: minefield repeatedly goes unresponsive for multiseconds when loading 7M file → minefield repeatedly goes unresponsive for multiseconds when loading 7M file. burning cycles in nsTextFrame::EnsureTextRun
Browser is responsive for me on trunk. It pauses at times during loading, but I don't see the symptoms of comment 0.
agreed. 4.0b3pre (with desktop) is much better. WFM
I'll try a more modest laptop, but I expect the same results
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.