Last Comment Bug 709452 - Accessing properties of the window as window.something is really slow
: Accessing properties of the window as window.something is really slow
Status: RESOLVED DUPLICATE of bug 964915
: perf
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: 9 Branch
: x86 Mac OS X
-- normal with 1 vote (vote)
: ---
Assigned To: general
:
: Jason Orendorff [:jorendorff]
Mentors:
Depends on: 649887 903802
Blocks: WebJSPerf 824495
  Show dependency treegraph
 
Reported: 2011-12-10 01:21 PST by Boris Zbarsky [:bz] (still a bit busy)
Modified: 2014-05-28 09:48 PDT (History)
17 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description User image Boris Zbarsky [:bz] (still a bit busy) 2011-12-10 01:21:18 PST
I just wrote a small testcase like so:

    var start = new Date;
    function f() {
    }
    for (var i = 0; i < 100000; ++i) {
                        window.mozRequestAnimationFrame(f);
    }
    var end = new Date;

This runs in 250ms on my machine.  If I take out the "window." bit, it runs in closer to 100ms.

The issue, of course, is that "window" is a proxy.  There's a ton of overhead in the jit going in, in js::Wrapper::get, the forwarding to the underlying inner window etc.

Is there any way we could teach the jit about this situation?  For the same-compartment case, it seems like it could maybe just punch through to the inner window directly....
Comment 1 User image David Mandelin [:dmandelin] 2011-12-12 11:37:28 PST
I would imagine that's IC-able, although I don't know exactly what the guard would look like.

The timing shows us taking 1us without window vs 2.5us with. That's long for one operation but seems negligible for 60fps animation. I would like to optimize this someday but I haven't seen data yet showing that it's urgent.
Comment 2 User image Brian Hackett (:bhackett) 2011-12-12 12:04:13 PST
GETPROP ICs in IonMonkey (will) only have an input register for the object, and the guarding can be done on any aspect of the object (shape, type, identity, ...).  I imagine the 'window' access could get an identity guard on the window and then skip the wrapper, and this should work provided the underlying proxy state of window can't change (brain transplants?).  I don't know how this stuff will look with compartment-per-global.  2.5us (or 1us) is hugely expensive for a single property access, but I'd also like to see pages where this bites on before optimizing it.
Comment 3 User image Boris Zbarsky [:bz] (still a bit busy) 2011-12-12 12:18:27 PST
> That's long for one operation but seems negligible for 60fps animation. 

Oh, I just used mozRequestAnimationFrame because someone raised the issue of how it performs.  In practice, this can be any sufficiently fast (in terms of the Gecko code that runs) property access on the window; innerWidth, say.  People use that as window.innerWidth in tight loops sadly too often.

That said, I agree that this probably shouldn't be too high a priority until we see profiles with js::Wrapper in them.  Now if only we were commonly profiling random pages...
Comment 4 User image Boris Zbarsky [:bz] (still a bit busy) 2012-12-24 14:34:41 PST
This is showing up more as people use window.performance.now() a lot.
Comment 5 User image Guilherme Lima 2014-05-28 08:53:25 PDT
I get the same numbers with or without "window" (150ms) on Windows 7, on today's Nightly.
Comment 6 User image Boris Zbarsky [:bz] (still a bit busy) 2014-05-28 09:48:01 PDT
This got fixed in bug 964915.

*** This bug has been marked as a duplicate of bug 964915 ***

Note You need to log in before you can comment on or make changes to this bug.