Closed Bug 115388 Opened 23 years ago Closed 5 years ago

Rendering many text inputs is slow

Categories

(Core :: Layout: Form Controls, defect, P3)

Product:
Core
Component:
Layout: Form Controls
Platform:
x86
All
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
Future

People

(Reporter: maxwell, Unassigned)

References

(
URL
)

Details

(Keywords: perf, testcase)

Attachments

(5 files, 1 obsolete file)

Tidied-up version of reporter's testcase (now validates)
27.95 KB, text/html
Details
bigger testcase for fast computers
132.99 KB, text/html
Details
New profile
35.64 KB, text/plain
Details
Updated testcase from url
2.12 KB, text/html
Details
Same as previous but flushing out layout after setting innerHTML
2.15 KB, text/html
Details 
On pages that have a large number of form input boxes inside tables, Mozilla
will spend a long time laying the page out.  It takes 19.6 for my K6-2 333
running Linux to render the testcase listed above, pulling off the local harddrive.

While the page is being loaded, cpu usage is at 100% and the page remains blank
until the page is completely loaded, at which point the table is displayed. 
During this time, the browser UI in that window is mostly unresponsive.

This may be in part a X-Windows font problem as it only takes about 19 seconds
to render the page on a Win98 Pentium 233/MMX and ~8 on WinMe Celeron 900.
Reporter: what build are you using?
Both the Linux and WinMe tests were done with nightlies off the trunk from today (12/14/01).  The 
Win98 test was done with 0.9.6.  This issue has been present for awhile, I only now was able to track 
down the source of the problem.
The testcase at the URL above is missing a <body> tag, and has a stray closing
</center> tag.  Fixing these doesn't really make any difference (I'll attach my
tidied-up version in a mo)

The testcase is pretty pathological, featuring approx 350 (!) input boxes in a
table, but it shows the problem up nicely.

It causes mozilla on my system to lock up for approx 5-8 seconds while
rendering.  Win98SE, duron 800, 384MB ram, 2001121003.  IE5.5 renders it in
somewhat less than 0.5 seconds

Confirming, adding testcase & perf keywords.  Amending to severity normal since
there's no loss of function, it's just slow.  I suspect on a low-perf system,
however, this could look like a nasty hang - users don't like it when a program
stops responding for long periods.
Severity: major → normal
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: perf, testcase
oops, also another error in reporter's html : <input type="input"...> is
invalid, should be type="text".  Fixing this doesn't help :(
Temporarily moving to future until a milestone can be assigned.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
I'm not seeing this on win2k or linux (today's build).  It does a take a couple 
of seconds, but no where near 20 seconds.  For me most of the 2 or 3 seconds is 
just actual loading time for m the network.

marking WORKSFORME.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
I have to disagree here.

Working from a local file on my hard drive (so no network to confuse things):

IE6        : approx 0.5 secs (less than I can reliably measure with a stopwatch)
2002013003 : 7 secs

Most of this time is spent with the UI totally frozen, and the CPU pegged at
100%.  I don't doubt that the reporter's 233MHz machine takes about 19 seconds,
given that my stats are for an 800MHz machine.  AnthonyD, is your machine above
the 1.2GHz mark, by any chance?

True, this isn't horrific, but this looks like an excellent case for someone
with a profiler to have a looksee at.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Yes, I'm still seeing the same behavior as well.  While this machine is only a
K6-333 it has few performance issues with mozilla to the degree I see on this
page.  On a recent nightly, I get the same UI freeze as gav, and an informal
test loading from the hard drive takes ~19 seconds currently.
 Confirming that the problem exits on 2002012903 build on WIN2k. It takes more 
than 6 secs to load the page. IE takes less than a sec. performance...
I think this bug deserves a bit higher severity...
it manages to lock up my mozilla on a dual P-III 700 for a few seconds, 
so this is a pretty bad perf bug.
Whoa! something changed.  My testcase used to take about 7 secs on my machine. 
Now, with Win98SE/Moz 1.0 RC1, it's more like 3.5 seconds, or about 50% faster.
 Anyone else see any improvement?
Tested it on a K6-3 400 running Linux.
Both 0.99 and RC1 are about the same: ~ 8.5-9 seconds.
0.98 is ~ 16.5 seconds.

So it's quite a bit better in 0.99+ but still could use some work.  I plan on
profiling it as soon as I get a chance.
Computers are getting faster, and the original testcase is now
too quick to be realistically timed on my shiny new machine 
(as demonstrated by anthonyd in comment #6 above.

So here's a REALLY pathological testcase - 128 rows of 16 items, 
for a total of 2048 input boxes.  Unless I lost count somewhere.

This one keeps my athlon 1800+ busy for a good 10 seconds.

By comparing this one with the original testcase, it looks like 
things are just linear with number of input boxes.
mass reassign to default owner
Assignee: karnaze → table
Status: REOPENED → NEW
QA Contact: amar → madhur
Target Milestone: Future → ---
I suspect that the fix that just went in for bug 148636 might have helped here,
since it's talking about large numbers of input tags, too.  However, I'm not
going to be able to check this personally for at least a few days.  Can anyone
else see any improvement in post-20030521 builds?
Priority: -- → P3
Target Milestone: --- → Future
Depends on: 243588
*** Bug 252817 has been marked as a duplicate of this bug. ***
Replace defunct test URL with the testcase from the duplicate bug 252817

Amend Summary to remove reference to tables (seems to be linear with number of
inputs, without any influence from tables)
URL: http://www.xsta.cc/mc1.html → http://greymagic.com/dagon/ff.html
Summary: Calculating form input box sizes inside tables is slow → Rendering many text inputs is slow
Attached file testcase from the url (obsolete) — 

    
    

    
  
moving it to form controls based on comment 17
Assignee: layout.tables → nobody
Component: Layout: Tables → Layout: Form Controls
QA Contact: madhur → layout.form-controls

    
    

    
  
vista desktop 2.4GHz core duo

attachment 92141 [details]
FF trunk 1 sec 
IE8 2 sec

attachment 182235 [details] / http://www.greymagic.com/dagon/ff.html
FF trunk 30 sec
IE 362ms

can only guess without a profile - dupe of bug 335984?

    
    

    
  
Could be.  Ehsan, how does your patch look on these testcases?
Depends on: 221820

    
    

    
  
Er, actually ccing ehsan.  See comment 21?

    
    

    
  
(In reply to comment #21)
> Could be.  Ehsan, how does your patch look on these testcases?

It fixes this problem, mostly.

Without this patch, I get ~40s running the test in attachment 182235 [details].  With the patch in bug 221820 patch, I get ~950ms.

We could still do better.  Chrome dev channel on Mac gets ~400ms, and Safari excels at ~370ms.

    
    

    
  
Sure.  Once that lands, we should just profile whatever remains.

    
  
Depends on: 558954

    
  
Depends on: 558962

    
    

    
  

      
      
      
      

        Attached file
          
        New profile
        — 
      

    


  
I profiled the test case again after bug 221820 landed to get new perf data.

I used a slighly modified version of the test case.  The modified version mostly connects to shark and doesn't create an alert window.  I'm attaching the shark profile log here.

I read this carefully, mostly looking at editor/from control related parts.  I saw two possible optimizations that we can make, and filed them as bug 558954 and bug 558962, both with patches.  Other than that, I'm not sure what editor related optimizations are possible here.

    
    

    
  
The modified version of the test case lives here:

http://people.mozilla.org/~eakhgari/perf.html

    
    

    
  
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a5pre) Gecko/20100414 Minefield/3.7a5pre

Using the test URL with 15000 select elements does strange things for me. The others work fine, in less than a few seconds.

The browser uses 100% for a few seconds, then becomes unresponsive, as does X. Switching to a non-X terminal and kill -s ABRT firefox-bin gives me this report: http://crash-stats.mozilla.com/report/index/ce91fb74-4e9f-440d-a805-cddf32100414

Let me know if you want me to open a new bug.

    
    

    
  
(In reply to comment #27)
> Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a5pre) Gecko/20100414
> Minefield/3.7a5pre
> 
> Using the test URL with 15000 select elements does strange things for me. The
> others work fine, in less than a few seconds.

Which test are you mentioning?  The one in this bug has input elements, not select elements.

> The browser uses 100% for a few seconds, then becomes unresponsive, as does X.
> Switching to a non-X terminal and kill -s ABRT firefox-bin gives me this
> report:
> http://crash-stats.mozilla.com/report/index/ce91fb74-4e9f-440d-a805-cddf32100414
> 
> Let me know if you want me to open a new bug.

Yes, please, as the code to handle select elements is different.

    
    

    
  
(In reply to comment #28)
> (In reply to comment #27)
> > Using the test URL with 15000 select elements does strange things for me. The
> > others work fine, in less than a few seconds.
> 
> Which test are you mentioning?  The one in this bug has input elements, not
> select elements.

The URL for this bug (http://greymagic.com/dagon/ff.html) has an option to choose which form elements are created (it defaults to text inputs, but choosing select elements is what causes the problem for me).

> > Let me know if you want me to open a new bug.
> 
> Yes, please, as the code to handle select elements is different.

OK, I will do when I'm back on the Linux machine.

    
    

    
  
> OK, I will do when I'm back on the Linux machine.

It is already filed as bug 237842 so I commented there.

The times reported in the testcase at the URL for this bug are:

15000 text inputs: 4050 ms
15000 table rows:   441 ms
15000 list items:   178 ms
15000 spans:        266 ms
15 selects:           2 ms
150 selects:          6 ms
1500 selects:        49 ms
15000 selects:      489 ms

However, the last result (and the previous one to an extent) are misleading. Although that is the time reported in the alert, the time taken between starting the test and displaying that alert is much longer (at least a minute for the last case). This is on an old P4 2.8 GHz. During this time, the CPU is at 100%. Please let me know in that bug if there's anything I can do to help test or diagnose the problem.

Roc says in bug 237842 comment 14:

"We're constructing the dropdown widgets for the selects? Yeah, we should do
that lazily. In fact, we should just construct the dropdown widget when we need
to show the dropdown, and destroy it when we hide the dropdown. Probably a
small but significant pageload win. Sounds like something Ehsan might be
interested in."

    
    

    
  
(In reply to comment #30)
> Roc says in bug 237842 comment 14:
> 
> "We're constructing the dropdown widgets for the selects? Yeah, we should do
> that lazily. In fact, we should just construct the dropdown widget when we need
> to show the dropdown, and destroy it when we hide the dropdown. Probably a
> small but significant pageload win. Sounds like something Ehsan might be
> interested in."

Yep, I _am_ interested in working on that as well, but there are currently a lot of other stuff on my plate.  :-)  I hope I can find some time to work on that soon as well.

    
    

    
  


  

        Attachment #182235 -
        Attachment is obsolete: true

    
    

    
  


  
Previous testcase gives obviously bogus numbers in any UA with lazy layout object construction.

    
    

    
  
On that last testcase, I see us take about 2400ms for 15000 text inputs on my machine.  WebKit takes 2700ms.  Opera does 630ms.

    
    

    
  
At this point, something like 30% of the time is frame construction (including the anon content, editor state setup, etc).

55% is reflow.  6% is restyle processing (why?).  7% is the actual parsing.

As far as the reflow goes we end up doing the work twice because our first guess at the scrollbar state for the root scrollframe is wrong....

    
    

    
  
Odd, I thought we guessed "scrollbar needed" by default.

    
    

    
  
> Odd, I thought we guessed "scrollbar needed" by default.

For the first non-initial reflow.

In the testcase here the page fully loads, which includes at least one non-initial reflow.  Then the button press causes a content change that forces scrollbars to appear.  That reflow assumes that the scrollbar state is not changing by default, so assumes we won't ned scrollbars.

    
    

    
  
Adding overflow:scroll does make this about 20% faster, as expected....  Not sure how much we can do about that.

    
    

    
  
(In reply to Boris Zbarsky (:bz) from comment #35)
> At this point, something like 30% of the time is frame construction
> (including the anon content, editor state setup, etc).

Do you mean setting up nsHTMLEditorState objects?  That should be fairly cheap, I'd assume...

    
    

    
  
> Do you mean setting up nsHTMLEditorState objects? 

No.  About 6.5% of total time is under nsTextEditorState::BindToFrame, further breaking down as:

  0.2% self time
  2.1% nsTextControlFrame::UpdateValueDisplay (via InitializeRootNode)
  0.5% SetAttr from InitializeRootNode
  1.3% nsFrameSelection ctor (half of this is malloc, but also self time, some pref gets,
       etc).
  0.6% under nsTextEditorState::CreateRootNode
  0.4% nsTextInputSelectionImpl ctor (getting prefs and weak references)
  0.2% malloc called from BindToFrame

and various minor stuff.

    
    

    
  
An obvious optimization here would be to allocate a buffer for nsTypeSelection objects once instead of allocating each of them separately.  Do you think that makes sense?

In my local profile, most of the cost of the UpdateValueDisplay is coming from creating the text node, setting the class attribute on the anonymous div, and getting the editor's value.  I don't have any good solution for any of these... :(

    
    

    
  
Yeah, I don't either.

Again, in my case we're way better than WebKit.  Just a lot worse than Opera.  ;)

    
    

    
  
I think we can move on to other more important problems.

    
    

    
  
On my fast linux machine, we hit 50-70ms for 15000; Chrome is 90-100ms.


Status: NEW → RESOLVED
Closed: 23 years ago → 5 years ago
Resolution: --- → WORKSFORME

    
    

    
  
With the last testcase from bz, we're ~800ms, and Chrome is ~900ms



          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: