Closed Bug 496823 Opened 16 years ago Closed 16 years ago

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

Categories

(Core :: Layout, defect, P2)

Product:
Core
Component:
Layout
Platform:
x86
Windows XP
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.9.2a1
Tracking Flags:
Tracking Status
status1.9.2 --- beta1-fixed

People

(Reporter: alice0775, Assigned: bzbarsky)

References

Details

(Keywords: perf, regression, testcase)

Attachments

(2 files, 1 obsolete file)

test case
1.94 KB, text/html
Details
And even the right diff
5.25 KB, patch
roc
: review+
Details | Diff | Splinter Review
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
Attached 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: 16 years ago
Resolution: --- → DUPLICATE
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?
Attached 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: 16 years ago → 16 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: 16 years ago → 16 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.

Attachment

General

Creator:
Created:
Updated:
Size: