Friday, November 17th, 2006

JavaScript Code Inefficiencies from the IE team

Category: IE, JavaScript

Peter Gurevich has stepped up with another post on IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies.

The post is itself part one of a two parter, so this is 2.1 if you will, and covers inefficiencies in Javascript code:

Optimize String Manipulations by Avoiding Intermediate Results

Use Array.join('') over constantly += them together (as long as there is enough stringing going on (very rough: 7 – 13 values). A sample script that tells you the winner is included.

Running Code Using the ‘eval’ Statement is Expensive

The eval statement in JScript is both expensive in terms of performance and prone to error if the site is generating dynamically the script to be run. If you can remove it from your application you should do so. You’ll need to replace it with functional equivalents where the dynamically evaluated code can be simulated by changing the input parameters. This general wisdom not only leads to faster code in most cases but can also make your program more reliable and easy to understand. If arbitrary code is executing on the client machine it becomes hard to determine how it failed.

For those interested in the “why”, execution of an arbitrary string of script involves the construction of a new script runtime, copying the context of the currently executing script, manipulation of the runtime stack, and a bit of other work. This isn’t much different from running other code, but isn’t nearly as fast as writing the inline branching code to handle all of the possibilities of the dynamically generated code. There are obviously good uses for the eval statement, just examine your project thoroughly before taking a dependency on it.

Requirements of Eval for JSON Expressions

With JSON you will be using eval. Keep the data sizes small.

Switch Blocks are Linear Evaluation Tables

If you have a large switch it is best to break this down into a series of nested if statement comparisons, an array where you can perform a binary search, or my personal favorite a sparse array (hash-table).

Posted by Dion Almaer at 6:30 am

3.6 rating from 27 votes


Comments feed TrackBack URI

To be clear, the array.join(‘ ‘) approach for string concatenation is only truly effective in JScript; internal optimizations were made by Mozilla (and anything else using the Mozilla script engines) so that += concatenation is actually faster on those platforms. There are tests in Dojo showing this (although I don’t know where).

Comment by Tom Trenka — November 17, 2006

Tom You’re probably right but I think that += is boring when You have a lot of variables.
[a, big, list, of, objects, to, concat].join(”)

is always faster than
s += a;
s += big;
s += list
s += concat;

at least for developers, do You agree ?

I often use [var1, var2, ….., varN].join(something) when I’ve something to insert between every varM and I often prefere String.concat when there’s nothing to insert between varN.

”.concat(int, bool, null, arr, something)

I think concat native method is faster and better than join and += too, did Dojo Team test them ? :)
Final thing about array usage … push supports N arguments … then I wonder why there’s no [].push(var1, var2, var3, …. , varN) as example code in that page (that’s probably fast as String.concat is)

Comment by Andrea Giammarchi — November 17, 2006

Good thing i wont EVER use JScript. And JScript is different than JavaScript.

Eww.. JScript.. gives me the shivers..

Comment by scott — November 17, 2006

@scott: Your sites don’t support IE?

Comment by Michael Geary — November 17, 2006

My site does not support IE, but I am not concerned about the IE users. I actually tell them why it doesn’t render my CSS drop-down menu correctly and ask them to either ask MS to fix it in their browser or to use a more standards-compliant browser.

I don’t know why we keep the inefficient standard living…

Comment by Counsel — November 17, 2006

“My site does not support IE”, and that’s why nobody looks at it. “I actually tell them why it doesn’t render my CSS drop-down menu correctly and ask them to either ask MS to fix it in their browser or to use a more standards-compliant browser.”, that’s why they make jokes about you behind your back.

Comment by Snootz — November 17, 2006

I’ve been using a JSON parser that doesn’t use eval for a long time. If manually converting a JSON string into the javascript structures is more expensive than using eval, I don’t know. Either way, not using eval is safer from a security standpoint.

Comment by Andy — November 17, 2006

Maybe IE is some how slower than others, but to be honest, I never have any performance issue on the client side.

Comment by Cheng Guangnan — November 17, 2006

Link Listing – November 17, 2006

JavaScript Code Inefficiencies from the IE team [Via: Dion Almaer ] The S stands for Simple by Pete…

Trackback by Christopher Steen — November 17, 2006

Andrea: yes, we tested both. There’s an optimization in the Spidermonkey engine that makes += significantly more efficient on that engine, hence we provide the dojo.string.Builder class that uses the fastest underlying method for each engine. It’s nice that the IE team is telling us what’s broken in their engine, but these “guidelines” aren’t globally applicable, even on their engine. For instance, JScript is *brutally* slow at string manipulation, so for things that require a lot of it, eval() may in fact be faster in some cases…notably the ones where performance is an issue ;-)


Comment by Alex Russell — November 18, 2006

I think if You don’t send a JSON “Hello World” and You send more data or complex objects is not a good idea to use a dedicated parser instead of simple boult-in eval function.

I thought new Function isn’t better and isn’t safer too bacause inside a function the scope is the same of eval (JSON doesn’t accept var somename …) and if new Function is slower than eval I wonder why We should use that or other parsers … just use eval, that is perfectly designed, for example, for JSON interactions :)

Finally, eval read “our services” … then if something’s wrong, this is probably inside “your” server-side code, am I wrong ?

P.S. Alex : obviously, String.concat isn’t absolutely efficient for a String.Builder object … I was talking about in-line concatenations :)

str = str.concat(newvalue);

str = str.concat(newvalue);

.. is the same thing of a multiple += …
String.Builder should use array … or in your case, += with SpiderMonkey

Comment by Andrea Giammarchi — November 18, 2006

Can anybody explain me the bad thing with “window.OBJECT”?

Comment by Andre — November 19, 2006

Turkey Week Links (20 Nov)

.NET, C#, VB.NET Collection Object Reject changes in business objects Generic conversion of int value

Trackback by Hulkster — November 20, 2006

Here’s another one to be added:
if you wanna drill down on a specific DOM node, try to get there with as fewest iterations as possible. The fancy XPATH is great, but very poor on performance, especially on a large DOM Tree or IE.

Comment by Simon Jia — November 20, 2006

“Keep the data sizes small”… How about “Write a more optimized implementation of eval”? I really don’t get how big IT companies give “tips” to their users, trying to hide away the implementation issues they have. SRSLY, how long can the parsing of, for example, a 1MiB JSON file take on a modern PC?

Comment by Thomas Fuchs — November 21, 2006

Leave a comment

You must be logged in to post a comment.