If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Peacekeeper domJQueryContentFilters slower than in Chrome

VERIFIED FIXED in mozilla29

Status

()

Core
JavaScript Engine
VERIFIED FIXED
4 years ago
4 years ago

People

(Reporter: jandem, Unassigned)

Tracking

(Depends on: 2 bugs, Blocks: 1 bug)

unspecified
mozilla29
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
Created attachment 811992 [details]
Testcase

Original test here: http://www.peacekeeper.therichins.net/test21.html Attaching a stand-alone version with non-minified jQuery (same version, 1.6.4).

Numbers:

Chrome 31:  1953 ms
Nightly 27: 2957 ms

Test does just this:

    $("p:contains('Sega')");
    $("body *:empty");
    $("div:empty");
    $("div:hidden");
Flags: needinfo?(bzbarsky)
I see a ton of jitcode, GetElementIC::update, DoGetElemFallback (landing in HTMLCollectionBinding::get, but that's only 1/6 the time under DoGetElemFallback), regexp execution...

The DOM bits seem to be:

1) 16% querySelectorAll.  1/3 of this is the Throw() calls for the :contains() bits.  It
   ends up doing JS_DescribeStack and saving the stack....  A bunch of the rest is
   selector parsing.  Bug 863966 will help some.
2) 8% getting textContent.  A bunch of this seems to be string reallocation as we append
   stuff to it?
3) 8% is getting of offsetWidth.  No obvious hotspots there, just tons of calls.  
4) 5% is getting of offsetHeight.  Similar.

We can try to squeeze some blood out of those stones if needed....  Please file bugs blocking this one and needinfo me as needed?
Depends on: 863966
Flags: needinfo?(bzbarsky)
The patch for bug 863966 doesn't seem to affect this much.
(Reporter)

Updated

4 years ago
Depends on: 929507
(Reporter)

Updated

4 years ago
Depends on: 890722
No longer depends on: 929507
(Reporter)

Updated

4 years ago
Depends on: 929507
(Reporter)

Updated

4 years ago
Depends on: 929950
(Reporter)

Updated

4 years ago
Depends on: 932837
Depends on: 932870
(Reporter)

Comment 3

4 years ago
Bug 933475 doesn't affect this (much). I get 2145 ms with a m-i opt build, ~1950 ms with Chrome 32.

Comment 4

4 years ago
here we are on par with Chrome now, on linux at least. (~2100ms)
I guess this could be marked fixed if once verified on some other platform too.
Depends on: 951924
We are tied with Chrome on my MacBook Pro, too:

Firefox 26  ~3100 ms
Beta 27     ~2300 ms
Aurora 28   ~2100 ms
Nightly 29  ~2100 ms
Chrome 31   ~2100 ms

\o/
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
We should really retest on 32-bit windows.  Mac and 64-bit Linux numbers are nice, but Windows is what will get the press coverage.
Flags: needinfo?(cpeterson)
Reopening this bug until we test 32-bit Windows.
Status: RESOLVED → REOPENED
Flags: needinfo?(cpeterson)
Resolution: FIXED → ---

Comment 8

4 years ago
On a Windows7 laptop Nightly (32bit) and Chromium v34 both are ~3200ms
Status: REOPENED → RESOLVED
Last Resolved: 4 years ago4 years ago
Resolution: --- → FIXED
Awesome, thank you for testing that!

Comment 10

4 years ago
I get on Win7Pro:
chrome 31: around 2800 ms
Nightly (2013-12-21): around 3400 ms.
Hmm, I wonder why. Did you run the test several times?
Both in Nightly and Chrome the time seems to vary a bit.

Do you have any addons enabled?
Target Milestone: --- → mozilla29

Updated

4 years ago
Keywords: verifyme
Verified as fixed on:

Win 8 x86
Chrome: 2591 ms
Nightly 2013-09-30: 4233 ms
latest Aurora: 2529 ms

Ubuntu 13.04 x64
Chrome: 2616 ms
Nightly 2013-09-30: 4901 ms
latest Aurora: 3007 ms

Mac OS X 10.8.5
Chrome: 4313 ms
Nightly 2013-09-30: 6056 ms
latest Aurora: 3839 ms
Status: RESOLVED → VERIFIED
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.