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

Discussion in 'Javascript' started by ctman770@gmail.com, Sep 14, 2006.

  1. Guest

    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
     
    , Sep 14, 2006
    #1
    1. Advertising

  2. web.dev Guest

    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.
     
    web.dev, Sep 14, 2006
    #2
    1. Advertising

  3. Guest

    Thank you so much for the help.


    web.dev wrote:
    > 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.
     
    , Sep 14, 2006
    #3
  4. RobG Guest

    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, Sep 15, 2006
    #4
  5. Guest

    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:
    > 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
     
    , Sep 15, 2006
    #5
  6. RobG Guest

    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:
    > > 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.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
     
    RobG, Sep 15, 2006
    #6
  7. Re: What's faster, saving an HTML DOM node as a variable, or usinggetElementById?

    Hi,

    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
     
    Laurent Bugnion, Sep 15, 2006
    #7
  8. Guest

    напиÑав:
    > 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
     
    , Sep 15, 2006
    #8
  9. Re: What's faster, saving an HTML DOM node as a variable, or usinggetElementById?

    Hi,

    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
     
    Laurent Bugnion, Sep 15, 2006
    #9
  10. RobG Guest

    Laurent Bugnion wrote:
    > Hi,
    >
    > 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
     
    RobG, Sep 15, 2006
    #10
  11. Re: What's faster, saving an HTML DOM node as a variable, or usinggetElementById?

    Hi,

    RobG wrote:
    > Laurent Bugnion wrote:
    >
    >>Hi,
    >>
    >> 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
     
    Laurent Bugnion, Sep 15, 2006
    #11
  12. Guest

    > >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
     
    , Sep 16, 2006
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    0
    Views:
    1,495
  2. Replies:
    0
    Views:
    376
  3. Tjerk Wolterink
    Replies:
    2
    Views:
    1,443
    Dimitre Novatchev
    Aug 24, 2006
  4. KLEIN Stéphane
    Replies:
    3
    Views:
    442
    Paul Boddie
    Aug 25, 2008
  5. anagai
    Replies:
    1
    Views:
    139
Loading...

Share This Page