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).
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).
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)
Good thing i wont EVER use JScript. And JScript is different than JavaScript.
Eww.. JScript.. gives me the shivers..
@scott: Your sites don’t support IE?
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…
“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.
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.
Maybe IE is some how slower than others, but to be honest, I never have any performance issue on the client side.
Link Listing - November 17, 2006
JavaScript Code Inefficiencies from the IE team [Via: Dion Almaer ] The S stands for Simple by Pete…
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 ;-)
Regards
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
http://weblogs.asp.net/mschwarz/archive/2006/11/17/javascript-performance-access-to-global-variables-part-1.aspx
Can anybody explain me the bad thing with “window.OBJECT”?
Turkey Week Links (20 Nov)
.NET, C#, VB.NET Collection Object Reject changes in business objects Generic conversion of int value
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.
“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?