928318 - Chrome is 2x to 3x faster on jQuery event benchmark

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine: JIT, defect)

Description

[David Teller [:Yoric] - still alive but not very active]

This is something of a micro-benchmark, so I don't know whether this benchmark is pertinent. Still, here we go.

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

It is not a dom event test, but some odd js library test.
But let me re-profile.

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

As far as I see (and the case was the same last time I profiled this) we spend by far most
of the time in JS land.
Stuff in and under event dispatch take 17%

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

Hmm, actually bug 561491 is a bit different. That is there js shows up more badly.

Comment 4

[Jan de Mooij [:jandem]]

Are you also seeing a lot of time in Interpret? That shouldn't really happen anymore these days. I will take a closer look tomorrow.

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

So bug 561491 which is also about a jQuery event handling seems to spend lots of time in jit'ed
JS, and here quite some time is spent in other JS stuff.

Comment 6

[Jan de Mooij [:jandem]]

Mathias, I think we're running all kinds of unrelated scripts while running the benchmark: it looks like lodash.js (I think?) is dynamically creating functions with "with" statements for templating? Should this really happen while we're running the benchmark?

Comment 7

[Jan de Mooij [:jandem]]

We fixed some issues here, looks like there's a bit more to do but I don't have the time right now.

Comment 8

[Guilherme Lima]

Firefox 34 - 7600 op/s
Chrome 39 - 8600 op/s
Nightly 37 - 11500 op/s

on Windows 7 - WFM

Comment 9

[Greg Weng [:snowmantw][:gweng][:λ]]

I tested the latest revision (http://jsperf.com/always-return-on-jquery-events/4) and get the result:

Firefox 47.0 on Mac OS X 10.11

on with tag      262,789
on with class    272,596 

Chrome 51.0.2671.0 on Mac OS X 10.11.3

on with tag      282,490
on with class    277,755

---

As a result I don't think Firefox, at least Nightly, really lost the battle. However, I must admit this is not a serious test because there are no accumulated data. Is this still an issue need more investigation, or we can just close it according to such result?

Comment 10

[Mike Taylor [:miketaylr]]

AFAIK, jsperf is perma-down (Mathias and JDD can correct me if I'm wrong). Unless someone else has a copy of the test-case in question... not much to be done here.

Comment 11

[Mathias Bynens]

(In reply to Mike Taylor [:miketaylr] from comment #10)
> AFAIK, jsperf is perma-down (Mathias and JDD can correct me if I'm wrong).

It’s not perma-down — we’re working on getting a rewritten version of jsPerf up Real Soon Now™.

Comment 12

[Jan de Mooij [:jandem]]

Benchmark unavailable..

Comment 13

[Guilherme Lima]

Windows 10 results (jsperf is back)

Nightly 58 (19-10-2017) (async stack disabled)
on with tag      415,608
on with class    317,263

Chrome 61
on with tag      400,000
on with class    454,035

Comment 14

[Witold Baryluk]

Linux amd64

Nightly 66.0a1 (2019-01-03) (64-bit)
return on event     74,235 ops/s
no return on event  74,439 ops/s
on with tag        778,287 ops/s
on with class      725,701 ops/s

Chrome Version 72.0.3626.28 (Official Build) beta (64-bit)
return on event     66,096 ops/s
no return on event  66,342 ops/s
on with tag        727,619 ops/s
on with class      645,721 ops/s


Looks very good to me. In fact Firefox is faster.

Comment 15

[Olli Pettay [:smaug][[e-mail]]]

I get better results on Nightly/Windows than Chrome.
I think we can close this one and open new bugs for other performance issues.
WFM (since there isn't some particular fix here.)