The default bug view has changed. See this FAQ.

Accessing properties of the window as window.something is really slow

RESOLVED DUPLICATE of bug 964915

Status

()

Core
JavaScript Engine
RESOLVED DUPLICATE of bug 964915
5 years ago
3 years ago

People

(Reporter: bz, Unassigned)

Tracking

(Blocks: 2 bugs, {perf})

9 Branch
x86
Mac OS X
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

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....
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.
Blocks: 579390
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.
> 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...
This is showing up more as people use window.performance.now() a lot.
Depends on: 649887
Blocks: 824495
Depends on: 903802

Comment 5

3 years ago
I get the same numbers with or without "window" (150ms) on Windows 7, on today's Nightly.
This got fixed in bug 964915.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 964915
You need to log in before you can comment on or make changes to this bug.