Closed Bug 944127 Opened 6 years ago Closed 3 years ago

[Meta] jQuery $("<div>") DOM element append test is 1.3x slower than Chrome

Categories

(Core :: DOM: Core & HTML, defect)

defect
Not set
36

Tracking

()

RESOLVED INCOMPLETE
Tracking Status
platform-rel --- +
firefox50 --- affected

People

(Reporter: cpeterson, Assigned: smaug)

References

(Depends on 1 open bug, Blocks 1 open bug, )

Details

(Keywords: perf, Whiteboard: [platform-rel-jQuery][qf:p1])

Attachments

(2 files)

Compare the following jsperf test in Firefox and Chrome:
http://jsperf.com/jquery-performance-dom-creation

Chrome 31:
* with jquery: 274,230 ops/sec
* with pure js: 837,447 ops/sec // "pure js" is 3x faster than with jQuery

Firefox 28:
* with jquery: 14,740 ops/sec   // 19x slower than Chrome
* with pure js: 7,431 ops/sec   // 113x slower than Chrome and 2x slower than with jQuery?!

"with jquery" test case:
> var div = $("<div>");
> document.documentElement.appendChild(div[0]);

"with pure js" test case:
> var div = document.createElement("div")
> document.documentElement.appendChild(div);
pure js is at least all about appendChild. We're updating some content list all the time
...which ends up calling PositionIsBefore().
Same with jQuery case.
Summary: jQuery $("<div>") DOM element creation test is 100x slower than Chrome (and pure js test is 2x slower than with jQuery) → jQuery $("<div>") DOM element append test is 100x slower than Chrome (and pure js test is 2x slower than with jQuery)
That code in nsContentList is _old_.
> We're updating some content list all the time

Presumably another artefact of all the random extra code jsperf loads into the window it runs the tests in.

That said, shouldn't PositionIsBefore be pretty quick in this case, since we are in fact appending every time?
Depends on: 944149
With up-to-date it is harder to see where the time is spent, since I don't understand
what jsperf actually measures. Element creation and appendChild don't take too much time.
Attached file jquery test
js::regexp_exec takes about as much time as appendChild, and creating element a bit less.
Attached file non-jquery test
jquery test
Nightly (with bug 944149 fixed) - 1559ms
Chrome 31 - 749ms
Firefox Beta - slow script dialog
IE 11 - I gave up after running after more than 1 minute

non-jquery test
Nightly (with bug 944149 fixed) - 6373ms
Chrome 31 - 1934ms
Firefox Beta - slow script dialog
IE 11 - I gave up after running after more than 1 minute
Sorry, I switched the names. The first results are for the 'non-jquery' test, and the last results for the jquery one.
My test results on the latest Nightly 28 (with bug 944149) are similar to Guilherme's:

Aurora 27:   12,466 vs   8,294 ops/sec (jquery vs pure js)
Nightly 28: 125,497 vs 512,734 ops/sec
Chrome 31:  238,859 vs 723,286 ops/sec

Given that real content should construct an element tree before attaching it to the DOM instead of adding thousands of individual elements one-by-one, can we call this microbenchmark perf as "good enough" and resolve this bug as WORKSFORME? :)
Flags: needinfo?(bugs)
I wouldn't call this WFM. The jQuery case needs to be improved at least by fixing JS eng's regexp handling, and creating elements can be faster once we optimize extra addref/release out.
Flags: needinfo?(bugs)
Nightly 30 is much faster than Firefox 27, but Chrome 33 has also improved since this bug was filed:

* Firefox 27:  19,643 vs     8,593 ops/sec (jquery vs pure js)
* Nightly 30: 283,616 vs   988,758 ops/sec
* Chrome 33:  537,758 vs 1,247,556 ops/sec
Summary: jQuery $("<div>") DOM element append test is 100x slower than Chrome (and pure js test is 2x slower than with jQuery) → jQuery $("<div>") DOM element append test is 1.3x slower than Chrome
Whiteboard: [platform-rel-jQuery]
jsperf.com is down, but the standalone tests that Olli attached to this bug still run:

* The non-jquery test is still slightly (~15%) slower in Firefox than Chrome on my MacBook Pro, e.g. 515 ms in Firefox 50 vs 447 ms in Chrome 51.
* I let the jquery test run for over a minute before I gave up..
jquery test took 1546ms here, and non-jquery 476ms.
bug 984690 shows up rather badly here, in the DOM/layout side.
Depends on: 984690
platform-rel: --- → ?
platform-rel: ? → +
Rank: 36
Whiteboard: [platform-rel-jQuery] → [platform-rel-jQuery][qf]
Whiteboard: [platform-rel-jQuery][qf] → [platform-rel-jQuery][qf:p1]
Depends on: 1347643
Depends on: 1362894
Assignee: nobody → bugs
Flags: needinfo?(bugs)
Need to download the tests and run locally since they use http.
Chrome 60 dev seems to be a bit slower with jQuery test even in the best case, and when running the test
several times Chrome has some huge GC pauses causing the test to take up to 10x more time.
And same thing seems to happen without jQuery too, and speed it better in FF.
This is on 64 bit linux.

But there are things to optimize here. I'll file some bugs.
Depends on: 1368325
Depends on: 1368326
Hmm, on Windows Chrome is definitely faster (in those cases GC doesn't kick in).
Flags: needinfo?(bugs)
Summary: jQuery $("<div>") DOM element append test is 1.3x slower than Chrome → [Meta] jQuery $("<div>") DOM element append test is 1.3x slower than Chrome
Unusual issue with the non-jquery test in jsperf. We are now fast enough that we overflow the internal 
ATTRCHILD_ARRAY_MAX_CHILD_COUNT limit.

https://jsperf.com/simple-jquery-performance-test is testing just the jQuery part.

On a Windows 10 laptop Nightly gives 472,899 ops/sec, Chrome 152,892 ops/sec.
I think Chrome has regressed badly, but that also means that this particular bug isn't really actionable right now.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INCOMPLETE
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.