to substitute large text into the textarea takes long time(It takes 3 times than before)

RESOLVED FIXED in mozilla1.9.2a1

Status

()

defect
P2
normal
RESOLVED FIXED
10 years ago
10 years ago

People

(Reporter: alice0775, Assigned: bzbarsky)

Tracking

({perf, regression, testcase})

Trunk
mozilla1.9.2a1
x86
Windows XP
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9.2 +
in-testsuite ?

Firefox Tracking Flags

(status1.9.2 beta1-fixed)

Details

Attachments

(2 attachments, 1 obsolete attachment)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre) Gecko/20090607 Firefox/3.5.0 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090607 Minefield/3.6a1pre ID:20090607042549

to substitute large text into the textarea takes long time
It takes 3 times than before.


Reproducible: Always

Steps to Reproduce:
1.Start Minefield with New Profile
2.Load Test Case
3.Wait till a CPU and an HDD are settled down
4.Click any of links above making sample text lines.ex 5000
   (Please choose the numerical value depending on the ability of the CPU)
5.alert DIALOG of processing time appears.
Actual Results:  
takes 4.9 sec for 5000 lines on my WinXP machine(Pen4 1.2GHz,1GB RAM) .

Expected Results:  
takes 1.6 sec for 5000 lines on my WinXP machine(Pen4 1.2GHz,1GB RAM) .

Fine:
1561 msec/5000lines
http://hg.mozilla.org/mozilla-central/rev/68cfe7fb9f31
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090413
Minefield/3.6a1pre ID:20090413045916

Worse:
4884 msec/5000lines
http://hg.mozilla.org/mozilla-central/rev/68d9acc70491
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090414
Minefield/3.6a1pre ID:20090414100052

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=68cfe7fb9f31&tochange=68d9acc70491


Latest trunk is slow, too.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090607 Minefield/3.6a1pre ID:20090607042549
Posted file test case
Keywords: regression
Version: unspecified → Trunk
Keywords: testcase
Keywords: perf
Yes, yes it is. Alice, why did you file a new bug?
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 496360
The regression range is  different.
It is totally another bug.
Reopening.  Alice is absolutely right.
Blocks: 487449
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
So yeah, definitely a regression from bug 487449.  For block frames, getting the last sibling of the first child is a lot slower than what AppendFrames used to do, because the line list is double-linked.
Status: UNCONFIRMED → ASSIGNED
Component: General → Layout
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → layout
Assignee: nobody → bzbarsky
Flags: blocking1.9.2?
Posted patch Proposed fix (obsolete) — Splinter Review
Attachment #390554 - Flags: review?(roc)
Attachment #390554 - Attachment is obsolete: true
Attachment #390555 - Flags: review?(roc)
Attachment #390554 - Flags: review?(roc)
Confirming that the patch reduces the time taken by about a factor of 3.
Pushed http://hg.mozilla.org/mozilla-central/rev/622a29736f33
Status: ASSIGNED → RESOLVED
Closed: 10 years ago10 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Backed out: http://hg.mozilla.org/mozilla-central/rev/0468583f64f4

to see whether this might have caused the WinXP Txul regression.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Relanded as http://hg.mozilla.org/mozilla-central/rev/435d770fed54
Status: REOPENED → RESOLVED
Closed: 10 years ago10 years ago
Resolution: --- → FIXED
Flags: blocking1.9.2? → blocking1.9.2+
Priority: -- → P2
This landed before the 1.9.2 branchpoint.
Keywords: fixed1.9.2
Target Milestone: --- → mozilla1.9.2a1
You need to log in before you can comment on or make changes to this bug.