Storing document and window references in an object to get better performance

Question

I have one question and don't know do I do right thing.

I define window and document in objects or global variable in my pluins like this:

var myplugin = {
     document : document || {},
     window : window || {}
};

After I call that when I need like this:

myplugin.window.location.href = 'http://flyflyflymachine.etc';

And I would like to know do I get some better performance or is unnecessarily?

We generally use `window.location` right? Not the other one. — Praveen Kumar Purushothaman, Dec 26 '16 at 21:41
Are there more than one instance of `window` expected to be accessed? — guest271314, Dec 26 '16 at 21:44
`document || {}` — Since you don't declare `document` anywhere, if it isn't provided by the browser, that will throw a reference error and never reach the other side of the OR. — Quentin, Dec 26 '16 at 21:44
A long time ago one programmer tould me that storring document and window inside some global variable made better performance. — Ivijan Stefan Stipić, Dec 26 '16 at 21:45
A reference for that claim would be good. It goes against common sense: adding a reference (`myplugin` in this case) will make the lookup process longer. — trincot, Dec 26 '16 at 21:46
You can even use `location` without having to qualify it with `window` because location is a property on `window` object just like `localStorage`. Why wasting memory for garbage — Trash Can, Dec 26 '16 at 21:47
@IvijanStefanStipić _"yes more times."_ More instances of different `window` objects, or more instances of different objects accessing same `window`? — guest271314, Dec 26 '16 at 21:47

score 2 · Answer 1 · answered Dec 26 '16 at 21:56

2

As for performance, yes caching can help but you are not caching anything here. Merely replacing one lookup with another one (yourplugin.document vs window.document).

Actually in that case, just document is faster, but unless you are in a tight loop calling it a few thousand times, don't bother with these kind of nano optimisations.

answered Dec 26 '16 at 21:56

Casper Beyer

2,203
2
22
35

Ooohh, was OP trying to get an optimization by referencing `window` and `document`!? Yea, agreed, just don't do it. – DRAB Dec 26 '16 at 22:02
As far as I could tell, yeah and judging by the accepted, elaborated answer upon, yes. – Casper Beyer Dec 28 '16 at 05:39

score 1 · Answer 2 · answered Dec 26 '16 at 21:50

1

You seem to be concerned about window or document not existing. If, for example, this code were run from inside a Worker or NodeJS script, it would throw an error.

So you could "optimize" this in two ways:

Use a namespace with the this keyword (from global scope, this will refer to the global object)

var myPlugin = {};
(function myPluginNS(_global) {
  myPlugin.window = _global;
  myPlugin.document = _global.document || {};
})(this);

Use good ol' fashioned try-catch

var myPlugin = {};
try {
  myPlugin.window = window;
} catch (e) {
  myPlugin.window = {};
}
try {
  myPlugin.document = document;
} catch (e) {
  myPlugin.document = {};
}

Admittedly, not really an "optimization", but it will at least ensure your code can run in various JS run-times.

answered Dec 26 '16 at 21:50

DRAB

445
2
10

Inside a worker, you use `self` to refer to worker-specific window object which is subset of the host window object, you said to pass `this` into that function is **wrong** – Trash Can Dec 26 '16 at 21:58
@Dummy er.. can you post a snippet in which `this` does not work? It works in the code I've written. And I think you might be making things more confusing by saying "worker-specific window object" considering that a Worker does not have a "window". It has a global scope. – DRAB Dec 26 '16 at 22:01
`window` is just a shortcut to get the global scope object, but this global scope object isn't available in worker, instead each type of worker has its own scope object so using `window` inside a worker will throw an error. [Shared Worker Context](https://developer.mozilla.org/en-US/docs/Web/API/SharedWorkerGlobalScope). [Dedicated Worker Context](https://developer.mozilla.org/en-US/docs/Web/API/DedicatedWorkerGlobalScope). – Trash Can Dec 26 '16 at 22:06

score 1 · Accepted Answer · answered Dec 26 '16 at 23:59

In theory this kind of nano-optimization is more appplicable to nested functions created when a plugin is defined in terms of an IIFE instead of using an object literal initializer.

When code references a variable of object, the javascript engine has to search the current lexical scope record first, followed by any parent lexical scrope records until the variable or object definition is either found or proven not to have been defined.

Lexical scope records are created for for loops using let variable definitions and for functions to hold arguments and variables. So in a deeply nested for loop, in a deeply nested function, there could be a number of scope records to inspect before finding either window or document.

Making a copy of a global or outer function reference could reduce the number of scope records to search. A net performance gain will only arise if the overhead of making the copy is less than the overhead of the JavaSript engine searching the intermediary scope records, multiplied by the number of times the outer reference is used. This may be both rare in practice and difficult to prove if the gain is small.

The kind of plugin definition in the post, consisting of an "Object object" intializer instead of an IIFE does not meet the criteria of speeding up object reference searching and, indeed, could actually slow things down.

Storing document and window references in an object to get better performance

3 Answers3