What's faster, saving an HTML DOM node as a variable, or using getElementById?

[ctman770]

Hi Everyone,

Is it faster to save the precise location of an html dom node into a
variable in js, or to use getElementById everytime you need to access
the node?

I want to make my application as fast as possible. I have about 10-20
id tags that need to be accessed and modified from time to time. Would
the jvm perform slowly if I stored all of the dom node strings
"document.node.child...." into a huge js array?

Alternatively, would it also be slow if I had to use getElementById()
everytime I needed to access the node?

Thanks in advance for the help,
C

[web.dev]

ct******@gmail.com wrote:

Hi Everyone,

Is it faster to save the precise location of an html dom node into a
variable in js, or to use getElementById everytime you need to access
the node?

It would be faster to access a node that you have saved in a variable,
thus avoiding the time it takes to retrieve the node through
getElementById.

I want to make my application as fast as possible. I have about 10-20
id tags that need to be accessed and modified from time to time. Would
the jvm perform slowly if I stored all of the dom node strings
"document.node.child...." into a huge js array?

Javascript has no relation with Java Virtual Machine. The only thing
they both have in common is that they both start off with "java".

Alternatively, would it also be slow if I had to use getElementById()
everytime I needed to access the node?

If you had to access a node many times, then getElementById method
would be slower than if you had stored the node.

[ctman770]

Thank you so much for the help.
web.dev wrote:

ct******@gmail.com wrote:

Hi Everyone,

Is it faster to save the precise location of an html dom node into a
variable in js, or to use getElementById everytime you need to access
the node?

It would be faster to access a node that you have saved in a variable,
thus avoiding the time it takes to retrieve the node through
getElementById.

I want to make my application as fast as possible. I have about 10-20
id tags that need to be accessed and modified from time to time. Would
the jvm perform slowly if I stored all of the dom node strings
"document.node.child...." into a huge js array?

Javascript has no relation with Java Virtual Machine. The only thing
they both have in common is that they both start off with "java".

Alternatively, would it also be slow if I had to use getElementById()
everytime I needed to access the node?

If you had to access a node many times, then getElementById method
would be slower than if you had stored the node.

[RobG]

ct******@gmail.com wrote:

Hi Everyone,

Is it faster to save the precise location of an html dom node into a
variable in js, or to use getElementById everytime you need to access
the node?

That depends on how often you intend to access the node. If it is less
than a few hundred times in a tight loop, it likely makes no noticeable
difference.

I'd suggest testing it to find out where the tipping point is, then
deciding if you are ever likely to approach it.

I want to make my application as fast as possible. I have about 10-20
id tags that need to be accessed and modified from time to time. Would
the jvm perform slowly if I stored all of the dom node strings
"document.node.child...." into a huge js array?

I don't think an array of 20 items is huge. 20,000 is large.

Alternatively, would it also be slow if I had to use getElementById()
everytime I needed to access the node?

"Slow" is relative. If you are accessing the nodes infrequently, then
it likely makes zero difference to the perceived speed.

It is difficult to recommend a particular approach without knowing more
about the use to which it will be put, but generally I prefer to store
references in an array. I prefer to identify the nodes to store using
some strategy other than say a sequence of IDs (el-0, el-1, etc.), or a
list provided as an array from some other source.

To me it's much easier to wrap the elements in question in a div and
pass its ID to a function, then use getElementsByTagName or similar to
find the ndoes I want (maybe further distinguished by CSS class name)
and store references to them. For some nodes you can use a common name
attribute and getElementsByName, but that only suits a small sub-set of
elements.
--
Rob

[ctman770]

Actually,

One question that pops to my head now is that if I do end up using an
array to store id locations, if I make innerHTML replacements or
additions to other tags either before or after the div, do the
locations all go bad? In that case, it might be better to just use
getElementById all the time.

Thanks,
Clarence

RobG wrote:

ct******@gmail.com wrote:

Hi Everyone,

Is it faster to save the precise location of an html dom node into a
variable in js, or to use getElementById everytime you need to access
the node?

That depends on how often you intend to access the node. If it is less
than a few hundred times in a tight loop, it likely makes no noticeable
difference.

I'd suggest testing it to find out where the tipping point is, then
deciding if you are ever likely to approach it.

I want to make my application as fast as possible. I have about 10-20
id tags that need to be accessed and modified from time to time. Would
the jvm perform slowly if I stored all of the dom node strings
"document.node.child...." into a huge js array?

I don't think an array of 20 items is huge. 20,000 is large.

Alternatively, would it also be slow if I had to use getElementById()
everytime I needed to access the node?

"Slow" is relative. If you are accessing the nodes infrequently, then
it likely makes zero difference to the perceived speed.

It is difficult to recommend a particular approach without knowing more
about the use to which it will be put, but generally I prefer to store
references in an array. I prefer to identify the nodes to store using
some strategy other than say a sequence of IDs (el-0, el-1, etc.), or a
list provided as an array from some other source.

To me it's much easier to wrap the elements in question in a div and
pass its ID to a function, then use getElementsByTagName or similar to
find the ndoes I want (maybe further distinguished by CSS class name)
and store references to them. For some nodes you can use a common name
attribute and getElementsByName, but that only suits a small sub-set of
elements.
--
Rob

[RobG]

ct******@gmail.com wrote:

Actually,

Please reply below trimmed quotes of the bits you are replying to.

One question that pops to my head now is that if I do end up using an
array to store id locations, if I make innerHTML replacements or

If you replace a node, then your stored reference is useless,
regardless of how you replaced the node. The best idea is to update
the reference at the same time you replace the node. I think you'll
have exaclty the same issue using IDs - you'll have to ensure either
the new node has the same ID as the one it is replacing, or that you
update your referencing scheme (which might be a list of IDs in an
array).

The use of innerHTML or DOM to create/replace the node just changes the
method used to maintain references. You may lean toward innerHTML
because in IE it is much, much faster than using DOM. But for other
browsers, DOM tends to be just as fast as innerHTML (in some it is
faster).

additions to other tags either before or after the div, do the
locations all go bad? In that case, it might be better to just use
getElementById all the time.

Modifing other parts of the DOM will not affect either method of
referencing an element.

RobG wrote:

ct******@gmail.com wrote:

Hi Everyone,
>
Is it faster to save the precise location of an html dom node into a
variable in js, or to use getElementById everytime you need to access
the node?

That depends on how often you intend to access the node. If it is less
than a few hundred times in a tight loop, it likely makes no noticeable
difference.

I'd suggest testing it to find out where the tipping point is, then
deciding if you are ever likely to approach it.

For the sake of it, below is a simple test. Using an array of
references is much faster if you leave out building the array. If the
time taken to build the array is included, it is still a bit faster
than using getElementById every time.

So if your elements are reasonably static, then the stored references
is much faster (but only noticeably for more than say 100 elements in a
tight loop). If they aren't, it is still likely marginally faster to
update the array of references and use that. Incidentally, on my
machine, Firefox runs the following test in about 500 ms, IE takes
about 2500ms (that is, 5 times longer).
<script type="text/javascript">

function hideAllByID(){
var s = new Date();
var i = 0;
var x;
while ((x = document.getElementById('d' + i++))){
x.style.display = 'none';
}
var f = new Date();
alert('Using getElementById: ' + (f-s));
}

function hideAllByRef(){
var refArray = [];
var s = new Date();
var i = 0;
while ((x = document.getElementById('d' + i++))){
refArray.push(x);
}
var f = new Date();
var msg = 'Load reference array: ' + (f-s);
i = refArray.length;
s = new Date();
while (i--){
refArray[i].style.display = 'none';
}
f = new Date();
msg += '\nHide elements: ' + (f-s);
alert(msg);
}

for (var i=0; i<1000; i++){
document.write('<div id="d' + i + '">div ' + i + '<\div>');
}

</script>
--
Rob

[Laurent Bugnion]

Hi,

ct******@gmail.com wrote:

Hi Everyone,

Is it faster to save the precise location of an html dom node into a
variable in js, or to use getElementById everytime you need to access
the node?

I want to make my application as fast as possible. I have about 10-20
id tags that need to be accessed and modified from time to time. Would
the jvm perform slowly if I stored all of the dom node strings
"document.node.child...." into a huge js array?

Alternatively, would it also be slow if I had to use getElementById()
everytime I needed to access the node?

Thanks in advance for the help,
C

Just wanted to add that for big documents and multiple DOM Level 2
accesses to the document, document.getElementById presents huge
performance problems. We found out that it's much, much faster to get
one node and then to use navigation (through properties like firstChild,
the children collection, nextSibling, etc...) to get to the nodes you
want to modify. I am talking 10 times faster or more.

HTH,
Laurent
--
Laurent Bugnion, GalaSoft
Software engineering: http://www.galasoft-LB.ch
Private/Malaysia: http://mypage.bluewin.ch/lbugnion
Support children in Calcutta: http://www.calcutta-espoir.ch

[scriptguru]

ct******@gmail.com напи�ав:

Hi Everyone,

Is it faster to save the precise location of an html dom node into a
variable in js, or to use getElementById everytime you need to access
the node?

I want to make my application as fast as possible. I have about 10-20
id tags that need to be accessed and modified from time to time. Would
the jvm perform slowly if I stored all of the dom node strings
"document.node.child...." into a huge js array?

Alternatively, would it also be slow if I had to use getElementById()
everytime I needed to access the node?

Thanks in advance for the help,
C

Be careful with cashing node references. getElementById can be slightly
slower but also it is always safer.
For example we saved some node reference in variable. Then we modified
document.body.innerHTML. Reference we saved is dead now.

Val Polyakh

[Laurent Bugnion]

Hi,

sc********@gmail.com wrote:

>
Be careful with cashing node references. getElementById can be slightly
slower but also it is always safer.
For example we saved some node reference in variable. Then we modified
document.body.innerHTML. Reference we saved is dead now.

Val Polyakh

Actually, it's worse than just dead, it's a zombie, a reference to an
object which won't be garbage-collected unless you set it explicitly to
null. That could be the source of many a memory leak.

HTH,
Laurent
--
Laurent Bugnion, GalaSoft
Software engineering: http://www.galasoft-LB.ch
PhotoAlbum: http://www.galasoft-LB.ch/pictures
Support children in Calcutta: http://www.calcutta-espoir.ch

[RobG]

Laurent Bugnion wrote:

Hi,

sc********@gmail.com wrote:

Be careful with cashing node references. getElementById can be slightly
slower but also it is always safer.
For example we saved some node reference in variable. Then we modified
document.body.innerHTML. Reference we saved is dead now.

Val Polyakh

Actually, it's worse than just dead, it's a zombie, a reference to an
object which won't be garbage-collected unless you set it explicitly to
null. That could be the source of many a memory leak.

That's not a memory leak, it's just poor coding - the memory will be
released when the page is replaced. Obviously if you are going to
store references you need to manage them.
--
Rob

[Laurent Bugnion]

Hi,

RobG wrote:

Laurent Bugnion wrote:

>>Hi,

sc********@gmail.com wrote:

>>>Be careful with cashing node references. getElementById can be slightly
slower but also it is always safer.
For example we saved some node reference in variable. Then we modified
document.body.innerHTML. Reference we saved is dead now.

Val Polyakh

Actually, it's worse than just dead, it's a zombie, a reference to an
object which won't be garbage-collected unless you set it explicitly to
null. That could be the source of many a memory leak.

That's not a memory leak, it's just poor coding - the memory will be
released when the page is replaced. Obviously if you are going to
store references you need to manage them.

I work in scenarios where the page is never refreshed, and the browser
stays on for up to two weeks (tested), sometimes more. I agree about the
bad coding, but in the end the memory still leaks ;-)

HTH,
Laurent
--
Laurent Bugnion, GalaSoft
Software engineering: http://www.galasoft-LB.ch
PhotoAlbum: http://www.galasoft-LB.ch/pictures
Support children in Calcutta: http://www.calcutta-espoir.ch

[scriptguru]

That could be the source of many a memory leak.

>
That's not a memory leak, it's just poor coding - the memory will be
released when the page is replaced.

The reason is a poor coding and the result is memory leak.
The memory will be released when the page will be refreshed or replaced
but sometimes pages can be not replaced for long time and browser eats
hundreds of megs.
Sure it is not browser related bug - it is human related.

Val