1861660 - Tiny JS demo is 1.4x slower in Nightly compared to Chrome

Status: NEW

(Core :: JavaScript Engine, task, P4)

Description

[Mayank Bansal]

Open the attached testcase (original testcase from https://github.com/xem/miniMandelbrot)

<canvas id=A><svg onload=for(Q=5e4;Q--;A.getContext2d.fillRect(Q%X,Q/X,1,I/X))for(V=W=0,X=I=297;I--/V;W=Z+Z+Q/2e4-1)Z=VW,V=VV-W*W+Q/99%3-2>

Nightly: https://share.firefox.dev/46YivuG (13s)
Chrome: https://share.firefox.dev/46PK2Po (9s)

I figure that the code is written in un-conventional manner and thats why it is slower.

Comment 1

[Mayank Bansal]

Attachment: index.html

Comment 2

[Jan de Mooij [:jandem]]

This is spending almost all of its time doing slow environment name lookups. Because of how this code is written, it all runs in an event handler context, where we use non-syntactic with objects to add DOM elements to the environment chain.

Comment 3

[Matthew Gaudet (he/him) [:mgaudet]]

Going to give this a lower-than-normal priority due to the event handler name lookup issues.

Perhaps we will have a better story eventually, but doubt it's high priority.

Comment 4

[Mayank Bansal]

Latest profile: https://share.firefox.dev/4gPLdTg (12s)
interestingly, the profiler shows that all the time is now spent in ion!

Bisection:
Bug 1916185: Support JSOp::GetBoundName in Warp. r=jandem
Differential Revision: https://phabricator.services.mozilla.com/D220792

Comment 5

[Iain Ireland [:iain]]

Looks like we're going generic in a couple of Ion ICs and spending all our time in the fallback stub (IonBindNameIC::update and IonGetNameIC::update). So we've moved from baseline to Ion, but we're still slow for the same reason as before (and for the same reason as before, this isn't a high priority to fix).