Closed
Bug 876846
Opened 11 years ago
Closed 7 years ago
jQuery $("#foo") is 3x slower in Gecko+SpiderMonkey than in Blink+V8
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
WORKSFORME
Tracking | Status | |
---|---|---|
platform-rel | --- | + |
People
(Reporter: bzbarsky, Unassigned)
References
(Blocks 1 open bug, )
Details
(Whiteboard: [platform-rel-jQuery])
Attachments
(1 file)
281 bytes,
text/html
|
Details |
See url field or attachment. We're 3x slower than Chrome on the $("#testid") bit. I did a profile and it shows that 42% of our time is under js::regexp_exec (mostly doing js::CreateRegExpMatchResult, which ends up doing slow js:DefineGeneric bits. Another 24% is under js::SetObjectElement, called from jitcode. The rest seems at first glance to probably be jitcode.
Reporter | ||
Comment 1•11 years ago
|
||
The relevant script bits seem to be in this function: init: function( selector, context, rootjQuery ) { and look like this: match = rquickExpr.exec( selector ); where we have: // A simple way to check for HTML strings // Prioritize #id over <tag> to avoid XSS via location.hash (#9521) // Strict HTML recognition (#11290: must start with <) rquickExpr = /^(?:\s*(<[\w\W]+>)[^>]*|#([\w-]*))$/, and then the code does: if ( match && (match[1] || !context) ) { if ( match[1] ) { ... // HANDLE: $(#id) } else { elem = document.getElementById( match[2] ); etc. So it really does want this "match" object. Can we speed up the match-result creation? Right now that's easily 33% of the testcase just on its own.
Reporter | ||
Comment 2•11 years ago
|
||
Note that we may want several different bugs on the different issues here, blocking this one. Please feel free to file as needed and put patches in those!
Reporter | ||
Comment 3•10 years ago
|
||
Fixing bug 879402 took our time on this testcase from 1720ns/call to 1100ns/call. Or on the jsperf testcase for the id get from 560,387 ops/s to 907,220 ops/s. For comparison, Chrome dev is at 650ns/call on the attached testcase and at 1,767,542 ops/s on jsperf. Profiling I see: * a bunch of time in jitcode * 23% under js::SetObjectElement (SetPropertyHelper, DefinePropertyOrElement, a bit of AddTypePropertyId, about half under ensureDenseElementsNoPackedCheck, mostly calling growElements). * 23% under regexp_Exec. Of this, 10% is the createArray, and half of that is malloc. Also, updateMallocCounter seems to be 3% (???). * 5% is getElementById. * 10% is js::CallProperty which is ending up doing js::PrimitiveToObject and baseops::GetProperty and such. Not sure whether that's tracked by bug 922272 already. mostly it seems to be the mallocs killing us at this point, apart from the CallProperty bit.
Depends on: 922272
Reporter | ||
Comment 4•10 years ago
|
||
Also, if the testcase is modified to use http://code.jquery.com/jquery-1.2.6.js instead of the more recent version it currently uses, we hit tons of bailouts. :(
Assignee | ||
Updated•10 years ago
|
Assignee: general → nobody
Comment 5•9 years ago
|
||
On Windows 7: Browser: testcase / jsperf Chrome 39: 1000~1200 / 1,150,970 Nightly 37: 550~650 / 1,694,621 On the jsperf, Nightly is faster on all "testid" tests but slower on all "testclass".
Updated•8 years ago
|
Whiteboard: [platform-rel-jQuery]
Updated•8 years ago
|
platform-rel: --- → ?
Updated•8 years ago
|
platform-rel: ? → +
Updated•8 years ago
|
Rank: 38
Comment 6•7 years ago
|
||
Maybe baku can take a quick look at more recent profiles here?
Flags: needinfo?(amarchesini)
Comment 7•7 years ago
|
||
I don't think we need to do anything here. I have better results than comment 5. I would mark this bug as resolved.
Flags: needinfo?(amarchesini)
Comment 8•7 years ago
|
||
Closing per comment 7 (maybe NOLONGERREPRODUCES is a better resolution than WORKSFORME ...).
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•