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?
The test below is with 10 text fields. Increase the test to several thousand and see the results. <html> <body> <h1>Example 8sca: Forms scalability</h1> <br><br> Below are x instances of <input type=text> <form> <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> </form> </body> </html>
-> HTML Form Controls (or Layout ?)
Assignee: Matti → rods
Component: Browser-General → HTML Form Controls
QA Contact: imajes-qa → tpreston
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! Sam
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. http://bugzilla.mozilla.org/show_bug.cgi?id=124685
I'm working build your patch. Sam
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
Depends on: 124685
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.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.