Open
Bug 724649
Opened 14 years ago
Updated 3 years ago
expansion script on translatewiki.net statistics page is slow in Firefox
Categories
(Core :: Layout, defect)
Tracking
()
UNCONFIRMED
People
(Reporter: amir.aharoni, Unassigned)
References
()
Details
First of all, i'm sorry about the lame summary. It should probably be changed to something more descriptive that would probably say that a particular JS function is slow. I'm not very good at profiling JavaScript (i'm learning).
To reproduce, go to the URL, scroll down to the table and click the link that says "[expand]" in the cell that says "MediaWiki extensions".
Clicking the link will add more rows to the table. On my machine this consistently takes about 8 seconds on Firefox and about 3 seconds on Chromium. The times on other machines on which i tried the times are comparable.
Comment 1•14 years ago
|
||
Amir, which Firefox version are you testing? I just tried this, and I'm seeing about 4 seconds each in both Chrome dev and a Firefox trunk nightly...
That said, a profile shows that the vast majority of the time (95% or so) is not spent in JS execution at all. It's spent doing layout when the page gets offsetWidth on elements. I'll bet money that this page's script does a whole bunch of "modify the style, then ask for offsetWidth" operations, which is deathly slow in all browsers. Just to put this in perspective, 3-4 seconds is longer than it takes a modern browser on my machine to lay out the entire html5 single-page spec. dcamp, robcee, this is _exactly_ the scenario that I'd like devtools to help authors with!
In terms of where time is spent, is's largely table reflow (unsurprisingly). There's a bunch of overflow-area getting from nsTableRowFrame::ReflowChildren, getting of used padding, ConsidrChildOverflow, intrinsic width computation, iteration over the cellmap, etc, etc.
Assignee: general → nobody
Component: JavaScript Engine → Layout
QA Contact: general → layout
Comment 2•14 years ago
|
||
In terms of where the offsetWidth gets actually come from, they come from the jQuery.expr.filters.hidden function, called from the PSEUDO function in jQuery code, called from Sizzle filtering code. This is called from jQuery selector goop matching (no surprise!) ":hidden", which is called from doAnimation. In particular, doAnimation does this:
var opt = jQuery.extend( {}, optall ),
isElement = this.nodeType === 1,
hidden = isElement && jQuery(this).is(":hidden"),
I'm a little confused about why reflow is involved, though. The entry point to all this junk is the $thisChildRows.fadeIn(); call that http://translatewiki.net/w/extensions/Translate/resources/ext.translate.special.languagestats.js makes, and that should just be animating opacity...
Comment 3•14 years ago
|
||
Oh wait. This isn't just animating opacity. It's also changing 'display' on the table rows, one by one, flushing out all layout in between. In particular, it's setting style.display="" on rows that all seem to have style.display == "none". This is done off show() call. show() _tries_ to do all the elements its given at once precisely to avoid this problem, but apparently it's being called on one element at a time. The caller is
jQuery animation goop, all the way up the stack to their main event dispatch loop.
Amir, can you tell whether the problem is the way the page calls jQuery or jQuery itself? I'd really hope it's the former.... I don't understand why jQuery would be setting display on elements one at a time here.
| Reporter | ||
Comment 4•14 years ago
|
||
(In reply to Boris Zbarsky (:bz) from comment #1)
> Amir, which Firefox version are you testing? I just tried this, and I'm
> seeing about 4 seconds each in both Chrome dev and a Firefox trunk nightly...
Windows XP SP3, Firefox Nightly 2012-02-06, Google Chrome Canary 19.0.1031.0.
Ubuntu 11.10: Firefox Aurora 2012-01-30, Chromium 15.0.874.106.
Both machines are Core Duo 2 GHz, 2GB RAM. And on both i experience a similar gap: about 8 seconds on Firefox and about 3 seconds on Chrome.
I'll check about your other questions.
Thanks a lot for your very quick and detailed reply.
| Reporter | ||
Comment 5•14 years ago
|
||
Now i tried on Nightly 2012-02-06 on Ubuntu - it went down from 8 seconds to about 6. Woot, but still more than 3.
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•