Calling Method faster then Retrieving Something From Memory

Question

So this is my question: Why would calling a method be faster then retrieving something from memory?

Noticed when an id attribute is specified on a DOM element, user agents automatically attach the element's reference on their global scope.

Since user agents already reference all elements, which have their id attribute specified, why would I need to use document.getElementById("")?

Within an application, I would:

//Retrieving the value, I could possibly write this two way.
<script>
var fromGlobalScope = myElement.value;
var documentGetById = document.getElementById("myElement").value;
</script>


<input id="myElement" value="someValue" />

Doing some research, it is supported by all major browser, but their may some browser that do not support, which will break.

However, I could simply write:

<script>

//See if the element is on the global scope.
var fromGlobalScope = myElement ||document.getElementById("myElement");

</script>

I believe patterned correctly, I can automatically have references to all elements that have an id attribute. I don't have to call document.getElementById();

Using an resident property and I wouldn't have to walk the DOM, would think there would be a good performance benefit.

I created a jsPerf to see the benefit: enter link description here

My surprise was using document.getElementById() was a lot faster?

So this is my question: Why would calling a method be faster then retrieving something from memory?

Using document.getElementById, I would be calling a method that may or may not walk the DOM. At least, I will be calling an address for the value.

With a property on the global scope that should be quickly available as it is placed in some memory location.

I have include jsPerf results below:

I created another jsPerf with another thought: explicitly setting a property on the window object

However, I still believe learning why can help with the mechanics that are at play, which may result in something helpful.

Answer 1

From HTML5 spec

5.2.4 Named access on the Window object

The Window interface supports named properties. The supported property names at any moment consist of the following, in tree order, ignoring later duplicates:

• the browsing context name of any child browsing context of the active document whose name is not the empty string,
• the value of the name content attribute for all a, applet, area, embed, form, frameset, img, and object elements in the active document that have a non-empty name content attribute, and
• the value of the id content attribute of any HTML element in the active document with a non-empty id content attribute.

So the browser will probably walk the DOM tree to resolve a named property. In contrast getElementById() just needs to look the id up in (say) a hash map.

While the browser could maintain a hash map of the first matching element to that algorithm, maintaining that map would impose a performance penalty that would rarely pay for itself. In contrast the browser is looking up elements by their id constantly, so it pays to keep the id map.