5 second hang in nsTextFrame while resize textarea with 250KB of text

NEW
Unassigned

Status

()

Core
Layout: Text
6 years ago
4 years ago

People

(Reporter: BenWa, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
Created attachment 679176 [details]
250KB of text

Profile: http://people.mozilla.com/~bgirard/cleopatra/#report=0f34a70ce0bcdeaf4ea03dcd13fb08123ac9682d

STR:
1) Take the text in the attachment and copy it into a resizable textarea. I used the bugzilla comment box
2) Resize the textarea using the bottom right stretcher.
3) The resizing is smooth and when released I see a 5 second hang.
(Reporter)

Comment 1

6 years ago
John, who's the best person to contact for this bug?
Is it just me, or is the profile showing tons of time in nsLineLayout::TrimTrailingWhitespace?  It's hard to tell, because the profiler stops showing function names after the nesting gets deep enough.  :(
(Reporter)

Comment 3

6 years ago
That's the frame tree limit. You can use the '->' icon to keep expending until we de-recursify the dom.
When I use that icon I get told all the samples are in the function that had just hit the limit.  It might be coincidence, of course.  Hence my question in comment 2.  The profile seems to show two hotspots, and both happen to fall at the frame tree limit?

Updated

5 years ago
Duplicate of this bug: 919332

Comment 6

5 years ago
(In reply to Benoit Girard (:BenWa) from comment #0)

> 3) The resizing is smooth and when released I see a 5 second hang.

In my issue bug 919332, the resizing *is not* smooth. Firefox becomes unresponsive before I release the handle.

I don't know whether these two issues are really duplicates. If I take the 5 seconds onto my issue, it gives me 1 big minute, not 3 hours - if the delay is linear with the size of the text.
> If I take the 5 seconds onto my issue, it gives me 1 big minute, not 3 hours

This takes so long because the algorithm is nonlinear.  Though I would expect it to be quadratic, in this case, giving you about 12 minutes.  Unless, of course, you're running into serious cache effects, in which case all bets are off.
(Reporter)

Comment 8

5 years ago
Sorry Boris I never answered your last question about the profiler. I've improved the UI quite a bit since the last year and the profile still seem valid. Is there anything we can do here since we're substantial behind the performance of Chrome here.
The better profiler UI helps a lot.

The time under TrimTrailingWhitespace is actually all under EnsureTextRun.  So need to figure out why we keep having to do that so much.
Component: Layout → Layout: Text
You need to log in before you can comment on or make changes to this bug.