812409 - Firefox performance issue

Status: RESOLVED WONTFIX

(Firefox :: Untriaged, defect)

Description

[Nam H]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:16.0) Gecko/20100101 Firefox/16.0
Build ID: 20121025210744

Steps to reproduce:

Comparing performance using CraigslistFusion script (Greasemonkey) here:

http://userscripts.org/scripts/review/57662

Version 9.0 of the script, between Firefox 16.0.2 and Chromium 20.0.1132.47, I see that scroll during loading of large list (with images) in Chromium is much smoother and more responsive (easier on the eyes), the listing appears to be consistently completed loading quicker.  It seems not only JavaScript is what needed to be looked into, but rendering also matter greatly.  For example, in testing, I created a page that JS generates 50,000 rows of random data (text length of 100 characters)  in an HTML table (with dynamic DOM node additions).  The JS completes quickly in Firefox (using JS code to measure time of completion), but the page finishes rendering much longer than that (measures by waiting to see a popup alert at the end of the rendering).  Chromium is much faster on the rendering of the page, even it's not much faster with Javascript.  What this means is that focus on JS performance is only 50% of the equation.


Actual results:

Is not as smooth or quick in rendering large page


Expected results:

Should render faster and smoother.

Comment 1

[Nam H]

Attachment: Test code

To run test, open the unzipped file with a web browser.  Click on the "create table" link.

Wait for it to complete.  Then click "Ok" on the popup when it's done.  Note that the popup shows 1/10th of the time it shows on the page (top left).

The time in the popup is the completion time of the Javascript.  The time in the top left corner (after clicking the OK button) is the total time.

So total rendering time is 10 times the Javascript code to populate the table.

Comment 2

[Dennis Jakobsen]

the browser is unresponsive for the entire period of creation after clicking the button

Comment 3

[Nam H]

Using a virtual machine, here's a quick number:

Chrome:

JS: 3.2 seconds
Total rendering: 16 seconds

Firefox:

JS: 5.3 seconds
Total rendering: 35 seconds

Chrome also shows the alert much quicker (in about 4 seconds) versus Firefox waiting the whole rendering to complete before the alert is shown.

With the numbers above, Firefox takes 65% more time than Chrome for JS code to run (5.3-3.2)/3.2*100%.
and 119% more time than Chrome (35-16)/16*100% for total completion time.

Comment 4

[Nam H]

btw, the numbers above varies depending on code start of the browsers, or on a page refresh.  However, a consistent result is that it takes much longer for FF and a period of unresponsiveness versus the Chrome's alert message was shown and processed (hide when clicked OK) while it's still rendering data.

Comment 5

[Nam H]

with test case, it's very easy to reproduce, why not even investigate, or move forward with this?  It's still in unconfirmed status.

Comment 6

[Tim Taubert [:ttaubert] (inactive)]

We're indeed slower than Chrome and spend almost all our time doing reflows. I don't think we're particularly interested in optimizing for a (really) badly written web page.

If this would be a real world code example it should create the whole table as a document fragment and then insert the whole thing at once. If you insert row after row this just hurts performance, especially when using tables.

Comment 7

[Nam H]

Premature resolution.  Please see attached to have the updated test, with the table added to the document body after all rows are created.  Same slow result (33 seconds versus 10).  Some other suggestions of using pure HTML, versus JS code.  I can create sample like that, but remember, the code that does the add only take few seconds, as you can see from the timer.

Comment 8

[Nam H]

Attachment: Sample code for creating a large table with the table added to the document body after rows are populated

Comment 9

[Justin [:JW_SoftvisionQA]]

Hey Tim,

Im assuming this issue has been resolved and can be closed?

Justin

Comment 10

[Tim Taubert [:ttaubert] (inactive)]

I have no idea. We should ask the reporter but they're not accepting ni? requests. Let's just close it.