IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

Tom — Fri, 17 Nov 2006 02:04:13 GMT

Now that's a long blog post ;)

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

Robin — Fri, 17 Nov 2006 02:40:02 GMT

I’m confused. Are we talking about Javascript or JScript here:

<i>most languages will heavily optimize this, as Justin talked about on his blog a couple of years ago, but JavaScript doesn’t</i>

Surely optimisation is done in the interpreter, not the language?

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

devil's advocate — Fri, 17 Nov 2006 03:11:24 GMT

why do I get the suspicion that this is a result of trying to speed up all that AJAX crap thats showing up these days

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

Maian — Fri, 17 Nov 2006 03:31:22 GMT

Good tips, but a couple nitpicks:

1) You should point out the main misuses of eval and how they can be avoided. For ex:

eval("document.forms." + name + ".value='foo'")

should be

document.forms[name].value = 'foo'

Actually that's a bad example, since document.forms isn't really a JS object; it's a native object. But in general:

eval("obj."+prop) => obj[prop]

2) JavaScript's associative array isn't Array; it's Object. Array is just an Object with a magical length property and array methods.

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

paul — Fri, 17 Nov 2006 03:34:42 GMT

can you please fix your sample code, to include proper tags! if you plan for others to learn from this code, it should be a "good" example.

e.g. all the "<br>" tags should be "<br/>".

Second, can you use a different style text (cough, cough) FIXED FONT for the samples, and make it a different color than the default links in this Blog!

You'll want to add [type="text/javascript"] to your script tags too. It is the default, yes, but again, you're trying to lead by example.

ps Thanks for not using a single UPPERCASE tag! This actually makes your code sample look much more professional.

Paul

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

joel — Fri, 17 Nov 2006 03:45:38 GMT

I don't remember .innerHTML being part of the DOM spec? or even supported by all browsers?

Web Developers don't write browser specific code, remember!?*

*Well, ok we often have to, to get around quirks, but I would have altered the example to be more x-browser/DOM compliant.

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

steve_web — Fri, 17 Nov 2006 03:49:40 GMT

I love how your InjectMangle function, so very clearly illustrates the button bug that we've be complaining about in the last thread.

so, any chance of some ETA's on these fixes? ETA's on the Bug tracking system?

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

joel — Fri, 17 Nov 2006 03:50:46 GMT

ah, before I get reamed... I meant .innerText, not .innerHTML which every browser seems to support now.

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

Tino Zijdel — Fri, 17 Nov 2006 04:16:20 GMT

I'm repeating myself: beware of browser-specific implementations

The fact that string-concatenations are slow in JScript is because of a poor implementation (not keeping a pointer to the end of the string). Only in JScript is the Array.join()-approach faster, in other javascript-capable browsers concatenations using the + operator are much faster.

Opera blogged recently ( http://dev.opera.com/articles/view/efficient-javascript/ ) that it is even better to do:

a = a + 'something';

a = a + 'something more';

than to do:

a = a + 'something' + 'something more';

which is true, except in JScript...

As for the 'necessity' of eval for JSON I also disagree; it's quite easy to create a parser for JSON in javascript that doesn't rely on eval()

For the last part, the switch block, I will do some testing. It might just be that this is implementation-specific as well.

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

Jeff L — Fri, 17 Nov 2006 04:33:43 GMT

Just another nitpick - your code sample above uses

setTimeout("CheckInject()", 1000);

wouldn't it be more efficient to just do

setTimeout(CheckInject,1000);

http://dev.opera.com/articles/view/efficient-javascript/?page=2#timeouts

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

Tino Zijdel — Fri, 17 Nov 2006 04:45:11 GMT

To nitpick some more: please don't write examples that rely on propriety extensions (innerHTML) or IE-only propriety extensions (innerText and elements with name/id being available in the global namespace*).

Also please use valid markup, which means adding a type attribute to your script starttags and properly escaping any endtags within script. You are posting on a high-profile blog so your examples should at least pass a simple validity-check.

* document.all should have been deprecated with IE5 and should have been extinguished in IE7.

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

Scott — Fri, 17 Nov 2006 05:51:33 GMT

I read the article and understood the concepts, but had a tough time following most of the examples. Having read the comments, it sounds like its for the best.

I've read in many places that I should never use X or Y, but nobody seems to be saying the correct way to be doing things. Hopefully you JavaScript masters out there can appreciate that I'm a little wary of blindly going to web sites and trying to learn the right way to do things for fear of actually learning the wrong way to do things. Can anybody recommend any good ones to me? I'm already planning to some day buy the two recent books, one by Jeremy Keith and the other by Peter Paul Koch, in case you were going to recommend those to me.

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

Maian — Fri, 17 Nov 2006 06:06:46 GMT

Actually, 'x' + 'y' would resolve to 'xy' during compile-time in some JavaScript engines, including either Spidermonkey (Mozilla's) or Rhino (Java equivalent) - I forgot. By compile-time, I mean the stage where the engine's parser builds up the parse tree before interpreting it (which would be run-time). This only works for adjacent string literals though, not vars containing strings.

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

Justin Rogers [MSFT] — Fri, 17 Nov 2006 06:57:45 GMT

I'll try to follow up with all of the comments, but the general gut check is that people don't like my style. Some people pointed out the lack of XHTML (yep, sorry IE doesn't support it), we made the mistake of referencing JavaScript in a couple of places which should probably be JScript, as we are clearly talking about our own implementation here and how to speed things up when using IE.

I've also noticed that some of the other browsers have their own performance optimizations. For instance, the setTimeout call above, noted as not optimal, is treated in IE in such a way as to be almost optimal (though we do generate one extra anonymous function that isn't needed).

The most interesting comment so far is on JSON though. I think there probably are more efficient parsers than the use of eval. In fact, I would hope that someone would provide one for public consumption. If you have something go on over to www.json.org and convince them to pick it up!

If the content of the post here tends to be too much about what not to do, the intent of the code samples is to provide a quick basic work-around for use with IE. These tips if you will are based on common scenarios that we've discovered can be improved and acted upon by the web developer now. These are not and will not be replacements for actual improvements in IE's implementation as we release new versions.

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

Wraith Daquell — Fri, 17 Nov 2006 06:58:29 GMT

Sour, sour, sour. I've come to a conclusion about commenting web developers which I won't share here.

I thought the optimizations, particularly the string manipulations, were quite good. I'll remember to use them. For those that look down at various aspects of JScript and its implementation, remember that IE is faster in other ways than Firefox or Opera. Even Superman had issues...

Use an object rather than an array?

Michael Bolin — Fri, 17 Nov 2006 10:55:32 GMT

If you're going to assign arbitrary properties to an object, as in this example:

var o = new Array();

o["DIV"] = Parser_Div;

o["SPAN"] = Parser_Span;

o["P"] = Parser_Para;

Why not instantiate o as an object instead:

var o = {};

Since you're not using o as a sequence, why do you instantiate it as an Array?

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

Mike — Fri, 17 Nov 2006 12:50:50 GMT

I would like to commend the IE team for publishing this article and developers should be aware as much as possible of these issues. As for myself I intend to write code for readability and maintainability.I use lots of switch statements for preciously this reason, I could change that and make my code slightly quicker in IE but no doubt it would have a detrimental effect in other browsers. Likewise string-concatenations I am not changing my code because of an implementation quirk in one browser. I wish all developers would do the same aim to write clear maintainable code, it is up to browser makers to optimize their iterpreters. If all developers did this the onus would fall on browser makers to sort out these problems.

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

Jeremy French — Fri, 17 Nov 2006 12:58:07 GMT

Array.join for string concatenations sounds like a good tip. It is only marginally less readable and I can see why this would speed things up.

However using a hash function instead of a case statement makes the code much much less readable. It also restricts the number of values you can have for each case and forces you to create a function for each case statement, neither of which you would allways want.

I am sure there are occasions where the optimised code would be needed, but for most cases readability and maintainability should take precedence.

Finally I would like to point out that "Most script code used for manipulating the IE DOM requires some sort of string manipulation" is not a good premise to start an article on. There are built in methods for manipulating the DOM which require no string manipulation at all.

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

Fri, 17 Nov 2006 13:08:27 GMT

You really should remove commenting from this web log. All the Mozilla morons are annoying.

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

Dao — Fri, 17 Nov 2006 13:45:01 GMT

Don't do this:

var markupBuilder = new Array();

but:

var markupBuilder = [];

Don't do this:

setTimeout("CheckInject()", 1000);

but:

setTimeout(CheckInject, 1000);

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

Dao — Fri, 17 Nov 2006 13:56:12 GMT

> var o = new Array();

> o["DIV"] = Parser_Div;

> o["SPAN"] = Parser_Span;

> o["P"] = Parser_Para;

Man, that's nonsense.

What you have here isn't an "associative array" but an array object where you add properties. But then there's no need to use an *array* object.

What it should look like:

> var o = new Object;

> o.DIV = Parser_Div;

> o.SPAN = Parser_Span;

> o.P = Parser_Para;

Which can be optimized further:

> var o = {

> DIV: Parser_Div,

> SPAN: Parser_Span,

> P: Parser_Para};

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

Sebastian Werner — Fri, 17 Nov 2006 14:42:42 GMT

Could you tell me if "new Function(code)" is a good replacement for eval? That could be a way to parse json without the scope latency brought by eval.

Example:

return eval(json_string);

vs.

return (new Function("return " + json_string))();

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

Mike — Fri, 17 Nov 2006 15:38:07 GMT

I agree with Dao but can he or someone else explain why using

var markupBuilder = [];

is better than

var markupBuilder = new Array();

Surely both do the same and create a new array object. I am talking about array creation here as correctly pointed out an object should have been used in the example.

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

Tobie Langel — Fri, 17 Nov 2006 16:27:29 GMT

<blockquote>You really should remove commenting from this web log. All the Mozilla morons are annoying.</blockquote>

That was funny!

Great article by the way, despite it being quite IE flavored.

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

Andrea Giammarchi — Fri, 17 Nov 2006 16:48:06 GMT

seems that You forget String.concat native method, supported by every browser, IE4 too ...

I've tested that

var bigString = someString.concat(a, b, 'c', d, e, f, g, h, i(), j)

... is even faster than array creation with a join solution

var bigString = [a, b, 'c', .... , j].join('')

and both are faster than 'plus sign' concatenations.

I often use String.concat starting from empy string too

return ''.concat(what, ever, you, need)

useful for example with CSS size (first element isn't a string)

return ''.concat(myInt32Size, 'px');

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

Dao — Fri, 17 Nov 2006 17:15:06 GMT

@Mike

> I agree with Dao but can he or someone else explain why using var markupBuilder = []; is better than var markupBuilder = new Array();

Because it's faster.

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

Stoyan — Fri, 17 Nov 2006 17:17:17 GMT

Sebastian, afaik new Function in no better than eval. You can check:

http://yuiblog.com/blog/2006/11/13/javascript-we-hardly-new-ya/

and

http://dev.opera.com/articles/view/efficient-javascript/?page=2

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

Dao — Fri, 17 Nov 2006 17:17:56 GMT

@Sebastian Werner

> Could you tell me if "new Function(code)" is a good replacement for eval?

I'm pretty sure it's as inefficient as eval.

JavaScript performance - access to global variables [part 1]

Ajax.NET Professional - AJAX and JSON made easy! — Fri, 17 Nov 2006 18:11:39 GMT

While reading several posts about JavaScript performance [ 1 ] [ 2 ] I did a simple test, too. My first

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

TheSteve — Fri, 17 Nov 2006 19:06:30 GMT

Excellent post. I could definitely use this as a reference if I needed to do some optimizations. I have a habit of optimizing all my code when I have the time to do it -- a habit I picked up from 3D programming.

At the same time, I hope the knowledge you have of these inefficiencies is put to good use in future IE versions.

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

cooperpx — Fri, 17 Nov 2006 19:49:27 GMT

@ Justin Rogers

"The most interesting comment so far is on JSON though. I think there probably are more efficient parsers than the use of eval. In fact, I would hope that someone would provide one for public consumption."

Can you please elaborate on this? How can a JavaScript JSON parser be faster than a native one? ~ or did I just misunderstand your post?

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

Jerry Pisk — Fri, 17 Nov 2006 20:07:41 GMT

I also find the fact that the article calls for standards when mentioning JSON but uses innerHTML and innerText quite amusing. Microsoft just do not get it.

As for Scott: the correct way to add elements to an existing document once it's parsed is through DOM (and no, innerHTML or inner Text are not part of DOM):

function BuildDiv(id, text) {

var div = document.createElement("div");

div.setAttribute("id", id);

div.appendChild(document.createTextNode(text);

return div;

}

The above works even in IE since at least IE5. In the end, this is what using innerHTML will end up in, the browser will parse it and create the objects for you. I don't understand why some people think concatenating strings is a better way to create the objects you need.

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

Dao — Fri, 17 Nov 2006 20:27:28 GMT

> How can a JavaScript JSON parser be faster than a native one?

Because you don't have to "construct a new script engine, copying the context of the currently executing script". I still doubt a custom parser would be faster, though.

innerHTML is non-standard but much faster

Michael Bolin — Fri, 17 Nov 2006 23:22:37 GMT

Yes, this is DOM compliant:

> function BuildDiv(id, text) {

> var div = document.createElement("div");

> div.setAttribute("id", id);

> div.appendChild(document.createTextNode(text);

> return div;

> }

But this is reality compliant:

div.innerHTML = text;

When you start generating a large chunk of HTML and want to insert it, using DOM operations is painfully slow and is not atomic (instead of "blitzing" the new HTML into the DOM, you would be gradually updating the DOM, which may have undesirable visual effects).

As this article is about improving performance, favoring innerHTML is the right way to go.

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

TMaster — Sat, 18 Nov 2006 01:23:33 GMT

***OFFTOPIC***

I'm afraid I found a bug in the IE7 feed functionality: I was (am) subscribed to http://google.blognewschannel.com/index.php/feed/, but ever since that URL started returning a HTTP 404 error code, ALL my feeds have stopped refreshing their content entirely. I now have to right click and select "Refresh All". I just updated the two 404ed feeds, and don't know yet if they're updating automatically again.

What is the current suggested way to report non-critical bugs in IE7?

Lots of links

JD on EP — Sat, 18 Nov 2006 01:45:24 GMT

Lots of links: When I have so many browser windows and tabs open it's time to harvest some... here are some links I've found this week that I found interesting, and you may too....

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

Sebastian Werner — Sat, 18 Nov 2006 01:53:27 GMT

@Stoyan and @Dao, regarding your comments. Have you seen this sentence from the Opera links you have posted?

"The Function constructor is not quite as bad as eval, since using it does not affect the code surrounding the use, but it can still be quite slow."

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

Kris Zyp — Sat, 18 Nov 2006 02:58:54 GMT

I realize it is very fashionable to bash IE these days, but the topic at hand is JavaScript performance not whether people should use "non-standard" innerHTML and innerText in examples. Anyway, it is rather naive, or at least seriously limiting to write JS on browsers and only use "standards" based functions. Standards are great, and I certainly encourage Microsoft to follow them, but as web devs, the reality is we program to what will work for the masses, and innerHTML probably one of mostly widely implemented DOM interactions that is available, regardless of what W3C has to say about it.

As far as JSON/evals, I believe that evals generally have a constant time component to their cost, therefore it may be possible to build a non-native JSON reader that is faster on very small snippets of JSON, but I also doubt that non-native reader could be anywhere close to as fast as an eval on all but very small JSON strings. I thought what Justin was referring to with performance degradation with large JSON was applying Douglas Crockford's JSON regex security checking (the JSON.parse function, that prevents functions from being included in JSON). However, if you are getting JSON from a trusted source (and if you are making AJAX calls to your own server, you can generally trust it), then you don't need to run the JSON regex security checker, and the slowness of the regex checks can be avoided. I don't see why an eval on long strings would be non-linear in cost, it is essentially the same parsing that occurs in script parsing.

Anyway, I appreciate that Microsoft is providing information about JScript optimization.

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

Benjamin Hawkes-Lewis — Sat, 18 Nov 2006 04:02:02 GMT

Paul,

"You'll want to add [type='text/javascript'] to your script tags too. It is the default, yes, but again, you're trying to lead by example."

Actually, this is misleading on two counts. First, the Content-Script-Type HTTP header can be used to specify the default scripting language for the intrinsic event attributes of elements (like ONCLICK), but that header does not apply to SCRIPT elements. The TYPE attribute of the SCRIPT element is an absolute requirement and has no default value, even if a Content-Script-Type header is included. See the specification for SCRIPT:

www.w3.org/TR/html4/interact/scripts.html#adef-type-SCRIPT

Second, "text/javascript" is officially obsoleted in favour of "application/javascript". See the IANA media types registry ( www.iana.org/assignments/media-types/ ) and RFC 4329: Scripting Media Types ( www.ietf.org/rfc/rfc4329.txt ). I don't think that media type is supported by Internet Explorer, however. I guess one could hide the reference to text/javascript behind a conditional comment; perhaps Justin Rogers could amend his example above?

"Thanks for not using a single UPPERCASE tag! This actually makes your code sample look much more professional."

HTML tags are not case sensitive. There is nothing unprofessional about uppercase HTML tags; they appear in uppercase in W3C specifications.

Justin Rogers,

"people don't like my style"

Nothing wrong with using HTML, but adding a TYPE attribute to SCRIPT and escaping end-tag open delimiters (</) within SCRIPT are not matters of style. On the later point, please consult:

www.w3.org/TR/html4/types.html#h-6.2

Your first SCRIPT element technically ends only six lines in, at:

markupBuilder.push("</

These are simple matters of writing standard HTML or writing gibberish. Please fix your example before too many people copy and paste it verbatim into their markup. That's what the INS element is for, after all. :)

(If I wanted to whinge about "style", I might suggest that it is always better to use external scripts to separate content from behaviour: www.sitepoint.com/print/javascript-from-scratch .)

Michael Bolin:

"instead of 'blitzing' the new HTML into the DOM, you would be gradually updating the DOM, which may have undesirable visual effects)."

Why not use DocumentFragment to build up a DOM section out of sight, then insert it all in one go?

TMaster:

"What is the current suggested way to report non-critical bugs in IE7?"

Phone support and the microsoft.public.internetexplorer.general newsgroup (yes, the closure of the public bug tracker does suck):

www.microsoft.com/windows/ie/support/default.mspx#ie7Support

Kris Zyp,

"innerHTML [is] probably one of mostly widely implemented DOM interactions that is available, regardless of what W3C has to say about it."

Maybe. But not all implementations are the same, as Ian Hickson has found while trying to write a backwards compatible, cross-browser specification for innerHTML for Web Applications 1.0:

ln.hixie.ch/?start=1158969783&count=1

Again, according to the Mozilla Developer Center: "when text is entered into a text input, IE will change the value attribute of the input's innerHTML property but Gecko browsers do not".

developer.mozilla.org/en/docs/DOM:element.innerHTML

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

Jace — Sat, 18 Nov 2006 04:55:36 GMT

@Benjamin Hawkes-Lewis

Lower-case text compresses better than upper-case reducing Internet congestion...

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

stanley — Sat, 18 Nov 2006 04:57:29 GMT

Why not make JScript parser more clever, or make a JScript code optimizer?

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

Benjamin Hawkes-Lewis — Sat, 18 Nov 2006 15:42:28 GMT

@Jace

"Lower-case text compresses better than upper-case reducing Internet congestion"

So Web Optimization's study appears to show ( www.websiteoptimization.com/speed/tweak/lowercase/ ), although their report confuses upper-case and mixed-case markup. Still, the logical advantage of lower-case markup, as far as I can gather, lies in the facts that:

1. GZIP encoding depends on the repetition of character sequences.

2. Character sequences like "table" are more likely to occur than "TABLE" in the content of the page.

However, removing whitespace from your code and obfuscating JavaScript also reduces congestion. But to maximize code readability, such techniques should only be applied to served content and don't really belong in maintained code or code samples. Whether the compression gains are generally worth obfuscating markup and code that users may wish to read and modify could be questioned. But I grant you that using all lower-case markup costs little in readability and gains a little in compressibility.

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

Dao — Sun, 19 Nov 2006 01:09:26 GMT

> But I grant you that using all lower-case markup costs little in readability and [...]

It doesn't cost anything in readability. In fact, a typography rule is to avoid uppercase text because it's hard to read.

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

Andre — Sun, 19 Nov 2006 13:22:15 GMT

Can anybody explaing me the problem with "window.OBJECT" instead of "OBJECT" at this post?

http://weblogs.asp.net/mschwarz/archive/2006/11/17/javascript-performance-access-to-global-variables-part-1.aspx

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

Benjamin Hawkes-Lewis — Sun, 19 Nov 2006 15:01:09 GMT

Dao,

"It doesn't cost anything in readability. In fact, a typography rule is to avoid uppercase text because it's hard to read."

Yes, that's a good point, one should avoid upper-case text for lengthy passages because it's hard to read. But upper-case text works GREAT as a formatting to distinguish a special type of text intermixed with other text (see what I did there). So while the tags themselves may be (slightly) less readable, it's easier to distinguish them amidst the text content, which arguably increases the scanability of the HTML as a whole.

But like I say, it's only a slight advantage. It's not enough to make me want to use upper-case text personally. (But then I (mostly) switched from XHTML 1.0 served as text/html to HTML 4.01, so I'm habituated to lower-case markup anyway.)

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

Tino Zijdel — Sun, 19 Nov 2006 17:21:43 GMT

Apologies in advance for a lengthy post

Justin, first of all I would like to comment on your 'style'. I really do appreciate your effort but their are certain things you need to keep in mind when writing about performance recommendations. Any article about this subject should come with a big red warning label saying 'beware of premature optimization and browser-specific implementations'. Also I object against using the term 'recommendations': most of the examples should not be considered good practices and you should only resort to certain optimization techniques when you have a compelling reason to do so. In 99% of all cases optimization on this level is not required and should be avoided at all cost to maintain readability of your code; f.i. using an array to do simple string-concatenation is completely illogical (more on that later).

Secondly I object to using propriety techniques in examples, especially when they are completely unrelated to what you want to explain. You should always try to use standard techniques or when you want to explain something that is related to any propriety technique put another big red label next to it saying that it is browser-specific. Funny thing is that in some of your examples using a standards technique will actually perform far better (more on that later).

In general when you use examples to show optimizations you should make sure that the example itself is optimized in every single way. I would like to demonstrate that in the explanation of the Array.join technique where you use the push method:

markupBuilder.push('somestring');

now this involves a method call which is actually more costly than doing this:

markupBuilder[markupBuilder.length] = 'somestring';

Now I did some research into the general slowness of string concetenation in IE's JScript implementation. It seems that when using strings smaller than 64KB there is no real performance issue, only beyond 64KB concatenation suddenly becomes 15 times slower (but is still linear). This is clearly an implementation issue that is specific to IE's JScript, other browsers don't suffer from this and just using the + operator performs best in these. So basically if you need to work with large strings and run into this IE-specific problem you should also apply this technique for IE only, for instance by using conditional compilation.

Now let's look at an example that involves loops:

for(var i = 0; i < tokenizer.length; i++) {}

here every iteration you need to check the length property of the tokenizer object which is slightly more costly than checking with a local variable. So you may want to rewrite this to:

for(var i = 0, l = tokenizer.length; i < l; i++) {}

or when order doesn't matter even to this:

var i = tokenizer.length;

while (i--) {}

Onto the use of propriety techniques: innerHTML

innerHTML is like a sledgehammer, it's great for manipulating large chunks of markup, but when you need to manipulate only a textNode you really should be using Element.firstChild.nodeValue which is around 6 times faster in IE. In your example you also insert a BR-element but if you had used a PRE-element i.s.o. a DIV for the output messages that would also not be necessary since you can than just use a linefeed.

Furthermore in your example each time you reference 'output' a lookup needs to be done. I thought you explained in your previous article that it is much better to cache that reference in a JS variable. That would also unjustify the need to use document.all-like lookups which, I admit, are slightly faster than using getElementById but since backwards compatibility with the ancient document.all object model is the root cause of many problems in IE with regards to DOM compliance it should be avoided at all cost so that one day it can be removed completely from IE.

Now I wouldn't want to rewrite my switches just yet. When such rewrite would mean trading a switch for a function call you will only see performance improvement when your switch-block contains more than a hundred or so cases; below that the added cost for the function call is more expensive than the plain lookup of the proper switch-case. So yet another example of premature optimization that should only be used in very specific cases and since HTML only has 91 different tagnames (including Q) I would still use a switch ;)

A far better tip would be to put the cases that are likely to occur most frequently 'on top' in your switch.

Oh, and yes, don't use an Array for associative properties, use an Object.

About my JSON comment: note that I didn't say that a JSON parser that doesn't rely on eval() would be faster. I simply don't know because I haven't made such a parser yet, but I may just follow up on that although I couldn't convince Douglas Crockford to consider my (faster) alternatives for toJsonString() either...

One last general remark: I feel that your examples are too big and complex to demonstrate the techniques at hand. Although it is nice to use real world-ish examples that should not be a goal in itself. The optimization tips now get overshadowed by the complexity of the examples themselves.

So far for my 'bashing', I hope it's helpfull :)

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

Dao — Sun, 19 Nov 2006 20:09:50 GMT

Nice post, Tino. Really helpful.

Btw, I just realized that Date is instantiated and thrown away 8 times in perfTestDivs. I know, it's only a test function and doesn't really matter (although the instantiation time adds to each result and thus adulterates the relative result). Anyway, you should take care of things like that while talking about performance.

According to the spec, HTML elements should have uppercase names

Michael Bolin — Mon, 20 Nov 2006 00:17:41 GMT

According to the HTML 4.01 spec at http://www.w3.org/TR/REC-html40/about.html#h-1.2.1:

"Element names are written in uppercase letters (e.g., BODY). Attribute names are written in lowercase letters (e.g., lang, onsubmit). Recall that in HTML, element and attribute names are case-insensitive; the convention is meant to encourage readability."

Just because the spec says element names should be in all caps (and argues that this improves readability, to boot!), do you expect everyone to start following the spec when lowercase names also work and improve download times? It's the same thing when it comes to using innerHTML instead of DOM operations.

Also, Benjamin Hawkes-Lewis, I appreciate the suggestion about DocumentFragment, but I don't believe it's supported correctly on IE6:

http://developer.mozilla.org/en/docs/Migrate_apps_from_Internet_Explorer_to_Mozilla#Document_fragments

Also, if you build up a DocumentFragment with DOM operations, then you don't get the performance benefits that you would get from using innerHTML.

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

Tino Zijdel — Mon, 20 Nov 2006 00:31:33 GMT

@Michael Bolin: that phrase you are quoting is about the conventions used within the specification document itself and is not a recommendation about actual markup. When I write about markup I also use uppercase; e.g. TABLE-element and such, but in actual markup I use lowercase tagnames.

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

Fred — Mon, 20 Nov 2006 07:05:39 GMT

Andre:

Using window.object requires two identifiers to be resolved: firstly "window", then "object". Removing "window" means you only need to resolve "object" (unless you want to circumvent a masking variable called "object" somewhere on the scope chain).

Dao:

In javascript, new Date() returns a date object set to the instant that it was created. It doesn't keep time with the system clock therefore the only way to get the current time is to create another Date object. Less than optimal? Yes, but what else is there?

Don't trust numbers less than 100ms since the resolution of the javascript Date object seems to be only about 15ms on most systems.

http://www.merlyn.demon.co.uk/js-dates.htm#Ress

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

Dao — Mon, 20 Nov 2006 10:32:25 GMT

> Using window.object requires two identifiers to be resolved: firstly "window", then "object". Removing "window" means you only need to resolve "object" (unless you want to circumvent a masking variable called "object" somewhere on the scope chain).

But since window is definitely the global scope, using window.foo means that the engine doesn't have to deal with scopes.

> In javascript, new Date() returns a date object set to the instant that it was created.

True, I forgot that (using Date rather seldom).

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

Dao — Mon, 20 Nov 2006 10:39:37 GMT

> Don't trust numbers less than 100ms since the resolution of the javascript Date object seems to be only about 15ms on most systems.

> http://www.merlyn.demon.co.uk/js-dates.htm#Ress

Not sure how this reflects the instantiation time ... What I know is that it doesn't depend on the system only, e.g. SpiderMonkey had a performance issue with Date.

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

lwz — Mon, 20 Nov 2006 10:44:35 GMT

In my opinion, since JScript is executed by an interpreter, the JScript interpreter should be able to evaluate the string passed to the function eval without constructing a new script runtime and copying the context of the currently executing script. Is there anything hindering such an execution?

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

elh4096 — Mon, 20 Nov 2006 18:12:36 GMT

Although Dao is correct in saying var o = {}; is the correct way of creating an object, it turns out that this is more likely to trigger the garbage collector in IE than var o = new Array(); Eric Lippert detailed in his blog how the garbage collector in jscript works.

http://blogs.msdn.com/ericlippert/archive/2003/09/17/53038.aspx

It sounds like this may no longer be needed for jscript 5.7 but it definitely provides a noticable impromentent for scripts that create lots of objects in IE 6 and lower.

In any case, I am pleased to see that MS is putting effort into was has appeared to me to be a very neglected area. Though I am hesitant to believe that this purely due to customer feedback and more like to do with internal MS projects like atlas (or whatever there ajax toolset is called) - purely speculative on my part though.

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

taylor — Tue, 21 Nov 2006 22:04:15 GMT

@all those quibbling about HTML tags,

HTML tags in uppercase, is the quickest way to get someone to laugh at your code.

Do a view source of any professional site (Google, MSN, Yahoo, etc.) Check out their source. You won't find <BODY> or <TABLE> or <DIV> tags, because they are associated directly with HTML from 1995.

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

Benjamin Hawkes-Lewis — Wed, 22 Nov 2006 04:52:23 GMT

"HTML tags in uppercase, is the quickest way to get someone to laugh at your code"

If that "someone" judges things by appearances I guess.

"Do a view source of any professional site (Google, MSN, Yahoo, etc.) Check out their source. You won't find <BODY> or <TABLE> or <DIV> tags, because they are associated directly with HTML from 1995."

Depends what you mean by "professional". Most of the (web) "professional" sites have jumped on the faux-XHTML bandwagon, including MSN from your list. For such sites, upper-case markup is is a matter of conformance not style.

If you'd bothered to look at the (allegedly) "professional" source code for this very blog page you're on now, you'd find that despite claiming (laughably) to be XHTML, it includes plenty of elements in upper-case (do a case-sensitive search for <BR>, <P>, <FONT>, <H6>, <B>, and so forth).

If I were to look at Google or Yahoo, I would find more important issues with their site than the case of their markup. Google's homepage has 50 validation errors; Yahoo's has 41. (The MSN page validates, so well done whoever did that! You still should have used HTML 4.01 Strict and a much cleaner design though.)

If you look at www.microsoft.com (which purports to be HTML 4.0 Transitional but naturally doesn't validate), you'll see <META>, <SCRIPT>, and <NOSCRIPT> all in upper-case. Or again, if you look at www.dell.com (which likewise claims to be HTML 4.0 Transitional but of course doesn't validate), you'll find <META>, <TITLE>, and <LINK> in upper-case. Or if you look at the homepage of IETF, you'll see <FORM> and <INPUT> in upper-case.

Case dismissed. ;)

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

Benjamin Hawkes-Lewis — Wed, 22 Nov 2006 04:52:43 GMT

"HTML tags in uppercase, is the quickest way to get someone to laugh at your code"

If that "someone" judges things by appearances I guess.

Case dismissed. ;)

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

Benjamin Hawkes-Lewis — Wed, 22 Nov 2006 05:05:46 GMT

"HTML tags in uppercase, is the quickest way to get someone to laugh at your code"

If that "someone" judges things by appearances I guess.

If I were to look at Google or Yahoo, I would find more important issues with their site than the case of their markup. Google's homepage has 50 validation errors; Yahoo's has 41. (The MSN page at least validates, so well done whoever did that!)

Case dismissed. ;)

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

Benjamin Hawkes-Lewis — Wed, 22 Nov 2006 05:09:03 GMT

"HTML tags in uppercase, is the quickest way to get someone to laugh at your code"

If that "someone" judges things by appearances I guess.

If I were to look at Google or Yahoo, I would find more important issues with their site than the case of their markup. Google's homepage has 50 validation errors; Yahoo's has 41. (The MSN page at least validates, so well done whoever did that!)

Case dismissed. ;)

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

Benjamin Hawkes-Lewis — Wed, 22 Nov 2006 05:15:14 GMT

Gargh... sorry for the repeat postings, folks. :( The site kept throwing up an error page. If anybody could delete the three extra ones that would be good.

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

samuel — Wed, 22 Nov 2006 05:23:45 GMT

this really does not seem gto be any more efficienyt.HOWEVER, I suppose it could prove itself to be most benefivcial in the future.

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

Tino Zijdel — Fri, 24 Nov 2006 03:07:04 GMT

It's a real pity neither Peter nor Justin seem to be eager to comment on my feedback even though I tried to bring it mildly this time (obviously they also overlooked my comments in part 1 because that certainly wasn't "good feedback" either). I won't go as far though as to say that I think this is again typical Microsoft behavior...

Please consider having your next item on this subject proofread by someone who knows something about the subject but isn't solely Microsoft-minded/oriented.

Oh yes, I tried a non-eval based parser for JSON in javascript but preliminary tests show that such a parser would be at least 10x slower than the eval-solution...

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

Lex — Fri, 24 Nov 2006 22:01:02 GMT

@Benjamin Hawkes-Lewis

You are right, lots of large sites don't comply with xhtml, or claim to be one thing, but are actually not.

I think taylor was spot on when s/he identified the use of UPPERCASE tags with amateurs. Anyone that is serious about web development, today (circa 2006) that is developing using upper case tags, might as well tell the world their HTML editor of choice is MS Word.

yeah, you can create a web page/site with Word, but no professional would dream of doing so.

Nothing against Word of course, it does help write great documents (once you kick clippy to the curb), but it wasn't designed for making web pages.

Lex

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

Renzo Kooi — Sat, 25 Nov 2006 10:29:15 GMT

As for string concatenation using an array, this is the simplest method I suppose:

['you ','can just ','concatenate anything ','like this ','right?'].join('')

Another question that's really annoying: IE7 messes up my tooltip script (see link) using a zoomed view. Would there be a hack to disable or modify the page zooming?

regards/RK

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

Benjamin Hawkes-Lewis — Sun, 26 Nov 2006 15:00:09 GMT

"I think taylor was spot on when s/he identified the use of UPPERCASE tags with amateurs. Anyone that is serious about web development, today (circa 2006) that is developing using upper case tags, might as well tell the world their HTML editor of choice is MS Word"

I'm somewhat suspicious of free-floating arguments from popularity ("Anyone"), authority ("serious"), and fashion ("circa 2006"), which aren't couched directly in terms of either technical merits or at least recommendations from standards organizations (who, we live in hope, have considered such merits). The same relentless pursuit of the novel drives people to create broken "XHTML" pages.

"Nothing against Word of course, it does help write great documents (once you kick clippy to the curb), but it wasn't designed for making web pages."

Or, rather, it /was/ designed for making web pages, but like most such programs it was designed with the wrong conceptual model for HTML+CSS (in other words, WYSIWIG) and without any serious attention to interoperability and accessibility.

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

joblxj@hotmail.com — Tue, 28 Nov 2006 10:26:26 GMT

How to shield the zoom in and zoom out function for IE7, please tell me using the javascript code, thanks

re: IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

Alex — Thu, 30 Nov 2006 22:35:35 GMT

It is maybe OT but how the appendChild work for IE7 ?

I am able to add a tr and td to an existing table but IE7 never works with.

It is really require to work only with FF2 ?

Well, for testings:

[code]<html>

<head>

<!--

function fillme(){

row = document.createElement('tr');

row.setAttribute('id','trel');

col1 = document.createElement('td');

col1.setAttribute('id','colnl');

col2 = document.createElement('td');

col2.setAttribute('id','coln2');

col3 = document.createElement('td');

col3.setAttribute('id','coln3');

col1.innerHTML = "TD 1 ";

col2.innerHTML = "TD 2 ";

col3.innerHTML = "TD 3 ";

row.appendChild(col1);

row.appendChild(col2);

row.appendChild(col3);

document.getElementById("eingabe").appendChild(row);

}

//-->

</script>

</head>

<body>

</table>

<!--

fillme();

//-->

</script>

</body>

</html>[/code]

I am really not happy about changes from the IE7-dev-Team between the last Beta and the first RC :(

IE+JScript Performance Recommendations Part 3: JavaScript Code Inefficiencies

IEBlog — Thu, 04 Jan 2007 23:03:19 GMT

Hello again, this is Peter Gurevich, Performance PM for IE. We have gotten a lot of good feedback from

Some JavaScript Links To Chew On

K. Scott Allen — Wed, 17 Jan 2007 08:02:32 GMT

I've flagged a few links to noteworthy JavaScript posts over the last month. Yahoo! Video: Advanced...

Some JavaScript Links To Chew On

Mirror blog entries from the industry — Wed, 17 Jan 2007 08:23:28 GMT

I've flagged a few links to noteworthy JavaScript posts over the last month. Yahoo! Video: Advanced JavaScript

Write better JScript code to execute within Internet Explorer (IE)

JScript Team Blog — Wed, 24 Jan 2007 17:43:36 GMT

This is the first ever blog written by me in my entire life time. Let me take some time to introduce

IE und JavaScript Performance Empfehlungen

Mon, 12 Feb 2007 14:58:48 GMT

Peter Gurevich, Performance Programm Manager des IE7 Teams, hat seine dreiteilige Serie zu o.g. Thema

IE + JavaScript Performance Recommendations

Markus' Blog — Tue, 13 Feb 2007 12:12:13 GMT

IE + JavaScript Performance Recommendations von Peter Gurevich, Programm Manager IE7 IE + JavaScript

Optimiser vos boucle for avec JavaScript

Atteint de Javascriptite aiguë [Cyril DURAND] — Sun, 16 Dec 2007 18:04:43 GMT

JavaScript est un langage " late binded " c'est à dire que chaque appel d'une propriété aura un coup

Optimiser vos boucle for avec JavaScript

Atteint de Javascriptite aiguë [Cyril DURAND] — Sun, 16 Dec 2007 18:41:16 GMT

JavaScript est un langage " late binded " c'est à dire que chaque appel d'une propriété aura un coût

Client side JavaScript optimization techniques

Peterson's Ponderings — Mon, 24 Dec 2007 19:42:09 GMT

Thanks to everyone that attended the December DevCares event in Chicago last week. One of the topics...

AJAX Performance Bestpractices

Gaurav Seth's WebLog — Sat, 22 Nov 2008 00:02:05 GMT

Recently someone asked me about the best practices for AJAX performance. Though this information is scattered