Closed Bug 115388 Opened 20 years ago Closed 1 year ago
Rendering many text inputs is slow
27.95 KB, text/html
132.99 KB, text/html
35.64 KB, text/plain
2.12 KB, text/html
2.15 KB, text/html
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.
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: 19 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?
*** 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)
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.
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.
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.
Status: NEW → RESOLVED
Closed: 19 years ago → 1 year ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.