bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

Performance problem with many text fields




Layout: View Rendering
16 years ago
16 years ago


(Reporter: Ivan Eisen, Assigned: Kevin McCluskey (gone))



Firefox Tracking Flags

(Not tracked)




16 years ago
I have a testcase with 20000 text fields.  It takes 1458 seconds to come up
on my 450 MHz machine.  If I shrink the visible area of the browser screen so that
no text fields will appear it takes 188 seconds.  Yet, if I make the window full
size after it completes the text fields paint immediately.  I found that
a routine called updateAllCoveringWidgets is where most of the 1458 seconds
are spent.  If there is no space for any the text fields on the screen the
routine isn't called.  The fact that I can resize the screen immediately
afterwards and get an instant repaint leads me to question why we are hitting
this routine so
hard if there is ant text fields visible.  Can we delay calling this routine
until we processed the last textfield?

Comment 1

16 years ago
The test below is with 10 text fields.  Increase the test to several thousand and
see the results.

<h1>Example 8sca: Forms scalability</h1>
Below are x instances of &lt;input type=text&gt;
<input type=text>
<input type=text>
<input type=text>
<input type=text>
<input type=text>
<input type=text>
<input type=text>
<input type=text>
<input type=text>
<input type=text>

-> HTML Form Controls (or Layout ?)
Assignee: Matti → rods
Component: Browser-General → HTML Form Controls
QA Contact: imajes-qa → tpreston

Comment 3

16 years ago
Ivan, pretty wild! Wondering, by varying N number of text 
fields, does it seem response follows order N-factorial or 
N**2 or sum(1..N) or something else recognizable? That may 
help claify priority this problem and help toward identify 
problematic loop/algorithm. Let's hope not N!

The view manager is the only thing that ever calls this function.
Assignee: rods → kmcclusk
Component: HTML Form Controls → Views
QA Contact: tpreston → petersen
Ivan, do you have a Mozilla build environment? I have a patch in this bug that
you could try. I'd love to hear if it solves your problem.


Comment 6

16 years ago
I'm working build your patch.

Comment 7

16 years ago
Robert's patch is effective to fix this testcase.

333 Mhz client to 4x700 MHz server over 100 mbps,
clearing client cache between each trial
(time secs, for several trials) 
w/o patch: 
300 text fields: 2.24, 2.31, 2.36
900 text fields: 7.77, 8.18, 7.93, 8.09
With patch:
300 text fields: 2.03, 2.18, 2.14. 2.14
900 text fields: 6.09, 6.62. 6.55, 6.54

Robert, patch circa early March. Takes several 'hunk fail' 
against current code because change/evolution base code. I 
needed hand apply several parts. I'm not very familiar this 
area code. Had to one/two places best-guess about way to 
code merge. While I think i did good, best would be you to 
do this. Is it possible you to bring patch up to current 
code and re-post? Thanks    


16 years ago
Priority: -- → P3
Target Milestone: --- → Future
The patch for bug 124685 was checked in a long time ago. Based on Sam's comment
"Robert's patch is effective to fix this testcase.", I'm closing this bug.
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.