Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Page 2 of 2 FirstFirst 12
Results 16 to 18 of 18
  1. #16
    Supreme Master coder! Old Pedant's Avatar
    Join Date
    Feb 2009
    Posts
    25,133
    Thanks
    75
    Thanked 4,338 Times in 4,304 Posts
    Just shows where the browser makers put the time in to make their code efficient.

    You would *think* that form["name"] *SHOULD* be faster than getElementsByName("name") (or roughly the same speed) because in general there will be fewer elements to inspect (fewer named <form> fields than named fields in the entire document).

    But clearly what is happening is that the browser makers have decided to create an index on all named elements (probably a hash table, but whatever) for use by getElementsByName() but are not bothering to create an index for the <form> elements. Likely that means form["name"] must perform a linear search instead.

    There's clearly no technical reason for what we are seeing. Just a choice of priorities by the browser makers.
    An optimist sees the glass as half full.
    A pessimist sees the glass as half empty.
    A realist drinks it no matter how much there is.

  2. #17
    Senior Coder Arbitrator's Avatar
    Join Date
    Mar 2006
    Location
    Splendora, Texas, United States of America
    Posts
    3,300
    Thanks
    28
    Thanked 275 Times in 269 Posts
    Quote Originally Posted by Old Pedant View Post
    You would *think* that form["name"] *SHOULD* be faster than getElementsByName("name") (or roughly the same speed) because in general there will be fewer elements to inspect (fewer named <form> fields than named fields in the entire document).
    I'd imagine that the same number of elements must be inspected for form.name because you can't rely on a form control being nested inside of its owner form element due to the new form attribute. Example:

    Code:
    <!doctype html>
    <html lang="en">
    	<head>
    		<meta charset="utf-8">
    		<title>Demo</title>
    	</head>
    	<body>
    		<form id="form"></form>
    		<input type="radio" form="form" name="x">
    		<script>
    			(function () {
    				"use strict";
    				var form = document.getElementById("form");
    				var paragraph = document.createElement("p");
    				if (form.x instanceof HTMLInputElement) {
    					paragraph.textContent = String(form.x); // "[object HTMLInputElement]"
    				}
    				else { // e.g., Windows Internet Explorer 11
    					paragraph.textContent = "This browser does not support the form attribute.";
    				}
    				document.body.appendChild(paragraph);
    			})();
    		</script>
    	</body>
    </html>
    Apparently, this disassociation can also occur due to the parsing algorithm if this note in the HTML spec is any indication: "The rules in this section are [...] complicated by rules in the HTML parser that, for historical reasons, can result in a form-associated element being associated with a form element that is not its ancestor."

    You also have to inspect twice the number of attributes because form.name also maps to id attributes.

    There's clearly no technical reason for what we are seeing. Just a choice of priorities by the browser makers.
    I'd imagine the lack of optimization has something to do with form.name being a legacy API that's specified for historical reasons.

    form.elements is a better API because it consistently returns one value type (an HTMLCollection object) whereas form.name can return a node list object, multiple types of element object, or undefined. When iterating over form.name, form.name can also return the same element multiple times in certain cases and throws a TypeError if you iterate to a name that doesn't exist (as you'd normally do on the last iteration when iterating over a node list).

    The tests back this up. In a revised test at http://jsperf.com/for-loop-cf/6, form.elements significantly outperforms form.name in every browser—by 1.7× in Chrome 29, 1.5× in Firefox 23, and 4× in Internet Explorer 11—though it's still slower than getElementsByName in Chrome and Firefox. IE11's performance is probably tainted by the fact that it doesn't support the form attribute yet.
    For every complex problem, there is an answer that is clear, simple, and wrong.

  3. #18
    Supreme Master coder! Old Pedant's Avatar
    Join Date
    Feb 2009
    Posts
    25,133
    Thanks
    75
    Thanked 4,338 Times in 4,304 Posts
    Very nice analysis. The funny thing is that I almost used form.elements but didn't think it would matter much! I guess, in the end, it really doesn't matter that much, compared to getElementsByName. But now all you've done is made me think form.elements could be improved. <grin/>
    An optimist sees the glass as half full.
    A pessimist sees the glass as half empty.
    A realist drinks it no matter how much there is.


 
Page 2 of 2 FirstFirst 12

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •