IE + JavaScript Performance Recommendations - Part 1

re: IE + JavaScript Performance Recommendations - Part 1

Tino Zijdel — Tue, 29 Aug 2006 01:47:18 GMT

You CalculateSum() example is hilarious, not only because of the use of document.all that has been deprecated since IE5 and should have been removed completely from IE7 because this backwards-compatibilty still causes global namespace pollution and many quirks, but mainly because a value-attribute from the DOM is always a string so you are not actually adding up 2 values, you are concatenating them.

For the rest a lot of this seems like premature optimization to me. Maybe you should mention something about the ultra-slow stringhandling of Microsoft's JScript and the way to overcome that by using arrays and join('') (yes, it's ugly).
When will you fix the simple things like substr(-2)?

re: IE + JavaScript Performance Recommendations - Part 1

foobar — Tue, 29 Aug 2006 02:15:22 GMT

I find Tino's comments hilarious, because he totally missed the point of the article.

Performance

Dave Massy's WebLog — Tue, 29 Aug 2006 02:18:06 GMT

For those asking about IE7 performance improvements there is the first of a set of blog posts covering...

re: IE + JavaScript Performance Recommendations - Part 1

blur — Tue, 29 Aug 2006 02:42:19 GMT

would be nice to see support for Javascript 1.7

re: IE + JavaScript Performance Recommendations - Part 1

Justin Rogers — Tue, 29 Aug 2006 03:01:43 GMT

Tino's comments aren't bad at all. My example was slightly contrived and does require a specialized control in order to work properly. If you wanted it to work with the default value property on a standard DOM element you'd need to do some conversion. The focus of the article was specifically on the things you could do to improve performance, not really ensure that each code sample stood on it's own right. In fact, we've found most people already have plenty of their own samples that they can apply these changes to for immediate performance wins.

Since I'm on the IE team, I can't really comment on "features" of the JScript language directly. In fact, most of the goodness above is about how JScript works, but is also very much applicable to how the IE DOM is constructed and how we interact with the JScript engine. I'd like to keep any postings we do on the topic of improving the link between the two components and not on the internal specifics of components I don't work on. If you have problems with IE on the other hand, we may be able to help out. So feel free to ask any JScript+IE integration questions or maybe just about IE performance issues you've had.

re: IE + JavaScript Performance Recommendations - Part 1

Mark Wubben — Tue, 29 Aug 2006 03:15:40 GMT

The problem with these examples is that they lead to unnecessary code obfuscation. As Tino noted, stay away from premature optimalization.

If I remember correctly one thing that slows JScript down is it's garbage collection: if you have a lot of objects it'll check them all, everytime, even if they stay in existance for a long time. It would be more efficient to decrease the checking of long-existing objects.

I'm also interested in how you are solving the memory leaks. Do you know about http://novemberborn.net/javascript/edgvl ?

re: IE + JavaScript Performance Recommendations - Part 1

cooperpx — Tue, 29 Aug 2006 03:21:30 GMT

yes, yes, yes! more plz! ;)

re: IE + JavaScript Performance Recommendations - Part 1

Dark Phoenix — Tue, 29 Aug 2006 03:40:21 GMT

Script optimization is always a good thing (though Tino's right, use of document.all should be avoided if possible).

I noticed that there isn't any word about the W3C Event Model, but I assume that's because in order to implement it, IE's entire event model would have to be rewritten (seeing as IE starts on the target element and bubbles the event upwards by default).

re: IE + JavaScript Performance Recommendations - Part 1

William J Edney — Tue, 29 Aug 2006 03:43:32 GMT

Justin -

Please pass along my thanks and 'excellent work' on the new version of JScript. We are doing heavy, heavy AJAX and have noticed significant speedups (not quite as fast as Mozilla on 'large working sets' but much, much faster than JScript 5.6).

Speaking of which, the new JScript 5.7 .dll seems to work fine when installed in a system using IE6 (and the performance improvements remain). Any chance we'll see this new .dll as part of a 'security patch update' or whatever to IE6?

Thanks again!! I owe you guys some major beers :-)

Cheers,

- Bill

re: IE + JavaScript Performance Recommendations - Part 1

William J Edney — Tue, 29 Aug 2006 03:44:46 GMT

Ooops - forgot to thank Peter for an excellent article. Looking forward to the next one :-)!

Cheers,

- Bill

re: IE + JavaScript Performance Recommendations - Part 1

Jeff — Tue, 29 Aug 2006 04:41:51 GMT

Installed the new IE7 RC1, after the installation any flash pages have stopped working, even after several installs of flash player the problem persists.

re: IE + JavaScript Performance Recommendations - Part 1

DaHcn — Tue, 29 Aug 2006 04:56:38 GMT

Good article, thanks!

Interesting Finds: August 28, 2006

Jason Haley — Tue, 29 Aug 2006 05:26:29 GMT

Interesting Finds: August 28, 2006

Jason Haley — Tue, 29 Aug 2006 05:36:27 GMT

re: IE + JavaScript Performance Recommendations - Part 1

Erik Arvidsson — Tue, 29 Aug 2006 09:41:35 GMT

Try the following:

var f = document.body.insertBefore;

alert(typeof f); // throws exception, should return "function"

alert(f instanceof Function); // throws exception, should return true

f.apply(document.body, [newChild, oldChild]); // throws as well

Yawn... This has been broken since IE4. No wonder IE is the Netscape of today.

Developing, Programming, Computer science » Blog Archive » Optimizing Javascript in Internet Explorer

Tue, 29 Aug 2006 10:18:46 GMT

PingBack from http://www.trapanator.com/blog/archives/197

re: IE + JavaScript Performance Recommendations - Part 1

kL — Tue, 29 Aug 2006 11:37:08 GMT

Couldn't these performance problems be fixed by adding small lookup cache?

IE JavaScript Performance Recommendations - Part 1

Dude, WTF?! — Tue, 29 Aug 2006 11:41:03 GMT

re: IE + JavaScript Performance Recommendations - Part 1

mikx — Tue, 29 Aug 2006 11:54:55 GMT

Great post. Really appreciate.

One of the typical examples for performance critical scripts is a client side sortable list - either based on a table or on DIVs - with more than a couple hundred rows and a dozen columns.

In intranet applications it is a common task to create a list control looking and behaving as similar as possible to the "real" Windows Forms ListView control - without using Java, ActiveX, .NET or something *g*

A post how the fastest script implementation from your point of view could look like would be awesome :)

re: IE + JavaScript Performance Recommendations - Part 1

Dao Gottwald — Tue, 29 Aug 2006 12:50:38 GMT

re: IE + JavaScript Performance Recommendations - Part 1

Andy C — Tue, 29 Aug 2006 12:55:57 GMT

Tino/Mark, the bit you seem to have missed is that scripts don't get optimized heavily by a compiler (because there isn't one), so it's important to know how to write performant code when necessary. Sure if you have a tiny bit of rarely called JS, then write for maintainability. If it's doing heavy work though, you need to put in some effort to make it work as well as possible.

re: IE + JavaScript Performance Recommendations - Part 1

Dao Gottwald — Tue, 29 Aug 2006 12:56:36 GMT

> I noticed that there isn't any word about the W3C Event Model, but I assume that's because in order to implement it, IE's entire event model would have to be rewritten (seeing as IE starts on the target element and bubbles the event upwards by default).

http://en.design-noir.de/webdev/JS/addEvent/

re: IE + JavaScript Performance Recommendations - Part 1

ROBO Design — Tue, 29 Aug 2006 13:27:02 GMT

Hello!

Actually, interesting post. Looking forward for the other two parts.

As for the previous comments, I agree. It's silly to talk about speed optimization when your implementation sucks. It sounds like "guys, look, we have a really good implementation, you - the web developers - have to work with us on this, fix your sites, make them faster, we've done the best we could".

Justin: yes, your examples don't have to be perfect, but please stop spreading bad coding practice.

I'll take this problem to another level: if a guy learning web development sees only bad examples all year-long, he'll code as bad as in the examples. I already *know* document.all and similar dirt is, *cough*, just dirt. However, beginners, novices, amateurs can't tell the difference. All of these bad examples go back into the head, you get used to them.

re: IE + JavaScript Performance Recommendations - Part 1

rgroth — Tue, 29 Aug 2006 16:31:19 GMT

wrong wrong wrong -- all the examples you cited could easily be optimized by the JS interpreter. If the scope hasn't changed there is no reason that the interpreter could not maintained a MRU cache of references per scope. Asking the developer to (a) trade readability for performance and (b) optimize for IE will have unpredictable results on other browsers and make the code harder to refactor later. Why not make the JS engine more intelligent at handling the examples above?

re: IE + JavaScript Performance Recommendations - Part 1

Vilx- — Tue, 29 Aug 2006 16:49:20 GMT

Some time ago I had to optimize some heavily inefficient JavaScripts/DHTML's. To find out, what exactly was slowing things down, I ran a series of tests on different aspects of IE's JS. What I found out was, that most everything works very very quickly, until it has to start performing lookups within DOM. For example, one of the slowest things was getElementById (and similar element-finding functions). Try making a page with 6000 checkboxes and then obtaining a reference to each of them. ;) IE's lookup times seem to be growing linearly with the increase of the elements. As if it was running through ALL of them instead of a binary search. Other browsers do that better. ;) A solution to this is to cache the reference once you have it - then everything works quickly.

Another nice thing would be if it would be possible to temporarily "turn off" rendering engine while performing some layout changes. For instance, I had to set up dynamically some >100 little "bars" inside a complex HTML when the page loaded. Each time I changed some property (width, position) of each bar, IE seemed to recalculate the whole page. Eventually I found out that if I positioned them absolutely, IE did it much faster, because they did not affect the rest of the page's layout. Still - seems like a workaround to me.

re: IE + JavaScript Performance Recommendations - Part 1

Grant — Tue, 29 Aug 2006 17:19:38 GMT

> var f = document.body.insertBefore;
> alert(typeof f); // throws exception, should return "function"

Alerts 'object' in IE 6.0.2900.2180.xpsp_sp2_gdr.050301-1519 w/ jscript.dll version 5.6.0.8831

IE has always returned 'object' for 'typeof' on DOM methods. And since methods on DOM objects are not defined by ECMA-262, but instead are DOM implementation specific, they can be 'typeof' anything the implementation requires.

However, my point is, alert(typeof document.body.insertBefore) does not "throw an exception" as described above, so the case of typeof x == 'object' can be caught and handled without a try/catch block.

> alert(f instanceof Function); // throws exception, should return true

Does not throw an exception in IE 6.0.2900.2180.xpsp_sp2_gdr.050301-1519 w/ jscript.dll version 5.6.0.8831, it alerts 'false', so again, this case can be caught and handled programmatically.

> f.apply(document.body, [newChild, oldChild]); // throws as well

This does generate an "Object doesn't support this property or method" error because 'f' isn't a Function, and does not have an apply method. However, because you can test whether 'f' has an apply method prior to using it, you can also avoid generating an error here.

> Yawn... This has been broken since IE4.
> No wonder IE is the Netscape of today.

Broken? Where is the specification for what a web browser DOM object's methods should return for 'typeof'?

Oh, that's right, the web browser DOM isn't part of the ECMA-262 specification, so it can behave however the implementation chooses to have it behave.

Anyway, this can be fixed pretty easily:

var f = document.body.insertBefore;
if (typeof f == 'object') {
f = new Function('x', 'y', 'document.body.insertBefore(x,y)');
}
alert(typeof f); // alerts 'function'
alert(f instanceof Function); // alerts 'true'
f.apply(document.body, [newChild, oldChild]); // works fine

re: IE + JavaScript Performance Recommendations - Part 1

Aedrin — Tue, 29 Aug 2006 17:28:00 GMT

I wonder how many of these "complainers" even know what IE's code looks like.

A large product like this isn't simply a "just add this feature and everyone will be happy".

There is a lot more to it. Firefox/Etc. have an unfair advantage in that they used an already working rendering engine, all they had to do was stick on a user interface that people would like.

IE has been around longer than that and thus inherits its past in new versions.

A rewrite would be lunatic, and they can't discard the product. It is part of everything.

re: IE + JavaScript Performance Recommendations - Part 1

Dave — Tue, 29 Aug 2006 17:43:09 GMT

> Anyway, this can be fixed pretty easily:
> var f = document.body.insertBefore;
> if (typeof f == 'object') {
> f = new Function('x', 'y', 'document.body.insertBefore(x,y)');
>}

Sure, you can wrap every "IE function" (to use Peter/Justin's nomenclature) in a real ECMA function object. That way the DOM methods and others like XMLHttpRequest will behave normally and have all the features like a prototype and constructor. It already works that way in Firefox and Opera, so you would only need to take the performance hit of wrapping everything for IE. Unfortunately, the methods are attached to each DOM element. I can't think of an easily reusable way to handle this IE quirkaround, it would have to be sprinkled everywhere you needed a real function from a DOM function. Anyone else have a better idea?

re: IE + JavaScript Performance Recommendations - Part 1

Andrew Eberhard — Tue, 29 Aug 2006 18:37:31 GMT

I've been doing heavy-duty AJAX applications (tens of thousands of lines of client side JScript code) in IE for over six years now and I have to say that IE JScript performance has steadily improved over those years. The suggestions mentioned here are known to me (except the function caching...thanks!), and I can say they really do make a huge difference particularly where lengthy iterations are concerned.

I'd really like to see Part II cover two additional topics (one of which was discussed above):

1. String concatenations: slow, fast, and ugly; a HOW TO. This should certainly include discussions of array.join("") as suggested above.

2. innerHTML vs. the DOM. I recall reading an MSDN article ages ago that suggested that when building a select tag with lots of options dynamically it was actually faster to replace the entire tag via the innerHTML of its parent than it was to iterate through the select tags options collection adding options one at a time. This remains fantastic advice to this day (the more options in the select tag the better). Any other such tips surrounding innerHTML vs. the DOM?

3. Dare I even ask: how browser specific are your suggestions? In my experience, Safari handles string concatenations much better than IE, and its array.join("") method is much slow making that hack a very IE specific tuning mechanism. Any thoughts?

Eagerly looking forward to Part II.

Thanks!

re: IE + JavaScript Performance Recommendations - Part 1

Steve — Tue, 29 Aug 2006 19:05:34 GMT

Good information, Peter. Looking forward to the next installment.

Recomendaciones de performance en Javascript « Blog de notas

Recomendaciones de performance en Javascript « Blog de notas — Tue, 29 Aug 2006 20:34:29 GMT

PingBack from http://javis.wordpress.com/2006/08/29/recomendaciones-de-performance-en-javascript/

re: IE + JavaScript Performance Recommendations - Part 1

Erik Arvidsson — Tue, 29 Aug 2006 21:02:19 GMT

Grant: You are right that typeof document.appendChild == "object" in IE6 but it is not an instance of Object (sigh). I got the exception in IE7rc1 when writing code in the address bar which is most likely just a UI bug.

It is also true that the W3C DOM does not enforce you to use real objects and methods. But it is encouraged to use the native language constructs where they fit and this is an obvious case.

Let me make an example of how bad this is. Let's say that the .NET implementation of the W3C DOM API was done in the way it is exposed to JScript. It would prevent people to use reflection (because methods are not methods and properties are not properties and interfaces are not interfaces) and you would not be able to put DOM nodes in a hash table that expects Object (because DOM nodes are not Objects).

To sum it up. This is ridiculous.

re: IE + JavaScript Performance Recommendations - Part 1

cagrET — Tue, 29 Aug 2006 21:35:53 GMT

>function IterateWorkOverCollection()
>{
> var funcAppendChild = document.getElementById(‘target’).appendChild;
> var length = myCollection.getItemCount();
>
> for(var index = 0; index<length; index++)
> {
> >funcAppendChild(myCollection[index]);
> }
>}
>
>
>--> looks like a bad idea:
>
>
>function X(){}
>X.prototype = {foo : 1, getFoo : function() { >return this.foo }};
>var y = new X;
>
>y.getFoo();
>>>> 1
>
>var z = y.getFoo;
>z();
>>>> reference to undefined property this.foo

Not necessary. DOM objects and Javascript objects have different/seperate implementations, so this might be able to work for DOM, and for JS not.

re: IE + JavaScript Performance Recommendations - Part 1

I Hate It — Tue, 29 Aug 2006 22:07:19 GMT

"2. innerHTML vs. the DOM. I recall reading an MSDN article ages ago that suggested that when building a select tag with lots of options dynamically it was actually faster to replace the entire tag via the innerHTML of its parent than it was to iterate through the select tags options collection adding options one at a time. This remains fantastic advice to this day (the more options in the select tag the better). Any other such tips surrounding innerHTML vs. the DOM? "

If I recall correctly, the article isn't regarding it being faster. Its about a bug in IE6 that will clear a select tag of all its options if one attempts to use innerHTML on the select tag to change it's contents. Due to the bug one must either:
-Rewrite the whole select tag
-Use W3C DOM methods to edit the options

re: IE + JavaScript Performance Recommendations - Part 1

Dao Gottwald — Tue, 29 Aug 2006 22:20:10 GMT

> Not necessary. DOM objects and Javascript objects have different/seperate implementations, so this might be able to work for DOM, and for JS not.

At least in IE, right?
I.e. this works in Firefox:
document.body.appendChild(document.createTextNode('abc'))
But this doesn't do anything:
var x = document.body.appendChild; x(document.createTextNode('abc'))

I don't think I want to break my sites in favor of questionable IE hacks.

re: IE + JavaScript Performance Recommendations - Part 1

Dao Gottwald — Tue, 29 Aug 2006 22:20:54 GMT

re: IE + JavaScript Performance Recommendations - Part 1

Andrew Eberhard — Wed, 30 Aug 2006 01:21:18 GMT

"If I recall correctly, the article isn't regarding it being faster. Its about a bug in IE6 that will clear a select tag of all its options if one attempts to use innerHTML on the select tag to change it's contents. Due to the bug one must either:
-Rewrite the whole select tag
-Use W3C DOM methods to edit the options"

Actually, I've never done it that way probably because of the bug you mention. I wrap the select tag in a span tag and call innerHTML on the span rather than the select.

re: IE + JavaScript Performance Recommendations - Part 1

Dark Phoenix — Wed, 30 Aug 2006 02:20:14 GMT

> > I noticed that there isn't any word about the W3C Event Model, but I assume that's because in order to implement it, IE's entire event model would have to be rewritten (seeing as IE starts on the target element and bubbles the event upwards by default).

> http://en.design-noir.de/webdev/JS/addEvent/

I know. A hack, to get around that IE doesn't support the full W3C Event Model. Note also that addEvent can't do capture events, which is exactly what I was referring to.

Javascript performance tips from the IE7 folks at Advanced CSS Design Resources - last-child.com

Wed, 30 Aug 2006 05:34:38 GMT

PingBack from http://www.last-child.com/javascript-performance-tips-from-the-ie7-folks/

re: IE + JavaScript Performance Recommendations - Part 1

PatriotB — Wed, 30 Aug 2006 06:56:05 GMT

"It is also true that the W3C DOM does not enforce you to use real objects and methods. But it is encouraged to use the native language constructs where they fit and this is an obvious case. ... To sum it up. This is ridiculous."

I disagree. First of all, the "native language" for MSHTML is C++, as that is what it is written in. Secondly, MSHTML's implementation seems to be primarily built around OLE Automation constructs (IDispatch), first created by the VB people long before JavaScript was invented; then, it was expanded to support Active Scripting concepts such as expandos (via IDispatchEx).

MSHTML object methods are just that: methods on the underlying COM object. MSHTML is completely "language-agnostic", and thus its methods aren't specially tooled for JavaScript: methods are not separate "function" objects. And I don't think that they should be. Besides the memory and performance implications that would have, it would require a huge re-engineering of 10 years' worth of code, for little or no benefit.

(That said, I'm not really sure why "typeof document.appendChild" would be object--I would expect it to fail altogether.)

hurry up!

web — Wed, 30 Aug 2006 07:45:55 GMT

Bookmarked *and* waiting for parts 2/3

re: IE + JavaScript Performance Recommendations - Part 1

Dao Gottwald — Wed, 30 Aug 2006 12:51:58 GMT

> Secondly, MSHTML's implementation seems to be primarily built around OLE Automation
> constructs (IDispatch), first created by the VB people long before JavaScript was invented;

Why should this bother a web developer? I really don't care about Microsoft's good reasons -- if they can't afford a decent JavaScript and DOM implementation, they shouldn't publish browsers. At least they shouldn't encourage "optimizations" that depend on their quirks.

> First of all, the "native language" for MSHTML is C++, as that is what it is written in.

> MSHTML object methods are just that: methods on the underlying COM object. MSHTML is
> completely "language-agnostic", and thus its methods aren't specially tooled for
> JavaScript: methods are not separate "function" objects.

Now Gecko's native language isn't JavaScript either, and at the same time (a) DOM does look native in JavaScript and (b) it's open to other languages (Python in Gecko 1.9). Must be magic.

re: IE + JavaScript Performance Recommendations - Part 1

Fduch — Wed, 30 Aug 2006 15:33:35 GMT

> Aedrin
> I wonder how many of these "complainers"
> even know what IE's code looks like.

I posted some ridiculous parts of IE source code, but moderators censored them. I can post again if anyone wants.

re: IE + JavaScript Performance Recommendations - Part 1

evg — Wed, 30 Aug 2006 15:39:25 GMT

@foobar
tino is absolutely right.
How Microsoft can promote standards, while using themselves non-standard code?
What's to the value of the article, while I find the variables part useful, the part of functions caching is totaly missing the point.
Why should I think, whether is is COM or anything else underneath? It is am implimentation details, and since I am not going to perform any heavy algorhitm using JavaScript, I do prefer to just keep my code clean (again, var helps keeping the code clean).

re: IE + JavaScript Performance Recommendations - Part 1

evg — Wed, 30 Aug 2006 15:54:16 GMT

@Aedrin
By the way, what is the engine you are talking about - gecko was created from the ground up, so is Opera, so is KHTML.
But I am stopping right there, since I have no intention starting a LONG flamewar.

Script Performance

hughpyle — Wed, 30 Aug 2006 17:26:48 GMT

If you're building anything complex with the Groove Forms tool, you probably use plenty of script code.&nbsp;...

re: IE + JavaScript Performance Recommendations - Part 1

arv — Wed, 30 Aug 2006 20:34:45 GMT

I had a big issue due to garbage collection in jscript till now, see the thread on (http://groups.google.com/group/microsoft.public.inetsdk.programming.scripting.jscript/browse_thread/thread/d758f148f03cd2ed/cc6143cd1b0d1e38?lnk=st&q=jscript+slow+performance+ie+firefox&rnum=2#cc6143cd1b0d1e3)

I had created a simple htm page (http://www.geocities.com/arvindsagarwal/test.htm) to test how jscript used to behave when lot of objects are created, and the results for ie 6 where really bad.

Good to see dramatic difference in ie7 rc1, and the page shows much better results. My application works much better now on ie7 rc1.

i had given up hopes of anything happening in this area since till last beta also there was no mention of anything to do with Jscript engine.

re: IE + JavaScript Performance Recommendations - Part 1

Aedrin — Wed, 30 Aug 2006 22:40:16 GMT

"gecko was created from the ground up"

Yes. Which is why I said that FireFox itself builds upon existing technologies (Gecko), as to where IE is built on its own technology (Trident).

re: IE + JavaScript Performance Recommendations - Part 1

Dark Phoenix — Wed, 30 Aug 2006 22:53:36 GMT

> "gecko was created from the ground up"

> Yes. Which is why I said that FireFox itself builds upon existing technologies (Gecko), as to where IE is built on its own technology (Trident).

...except that Gecko was created specifically for the Mozilla Suite, and Firefox is the browser component. Firefox WAS written from the ground up.

And anyway, I was under the impression that IE was originally an extension of the Mosaic browser...

re: IE + JavaScript Performance Recommendations - Part 1

PatriotB — Thu, 31 Aug 2006 05:33:32 GMT

"And anyway, I was under the impression that IE was originally an extension of the Mosaic browser... "

IE 1 and 2 were standalone EXEs whose rendering engine was, for the most part, based on Mosaic, from what I know.

IE 3 was componentized into several DLLs including the rendering engine, MSHTML.DLL. I don't know how much of IE3's MSHTML was based on Mosaic. However, I know that by IE4, MSHTML was entirely MS code (Trident), and no longer based on Mosiac at all.

Interestingly, up through IE6, MS still credits Mosaic in the About box. IE7, however, has removed that text.

re: IE + JavaScript Performance Recommendations - Part 1

Ted — Thu, 31 Aug 2006 06:25:53 GMT

<<I posted some ridiculous parts of IE source code, but moderators censored them. I can post again if anyone wants. >>

1> There's no reason for anyone to believe that your samples are in the product &/or ever were in IE.

2> If you do decide to post copyrighted source code, save Microsoft's lawyers some trouble and post your home address.

re: IE + JavaScript Performance Recommendations - Part 1

zmc — Thu, 31 Aug 2006 19:25:40 GMT

Excellent article! Can't wait for part 2. For those of you who are saying this is nothing but premature optimization, I think you have missed the point, which was to show you baseline examples of how to reproduce the cases. Knowing where the engine shines and where it doesn't surely is good thing.

I do have some questions for the IE+JScript integration team and I think some posters have already commented on it. When is IE going to expose the DOM prototypes? This really hurts developers considering most other browsers support it. I understand that DOM objects are refcounted COM objects and the JScript engine doesn't truly own them, but isn't there some way you could emulate them as special cases? There has to be a solution to this other than "IE is special and it's hard" right? Are all of the components of IE really that decoupled from eachother?

I think the root of this issue, as I understand it, is that JScript is a complete standalone component and could be used outside the context of MSHTML. By the same token, MSHTML is a standalone component, and can be used without JScript. This decoupling prevents the JScript team from adding code to deal specifically with MSHTML COM objects, which makes sense because it shouldn't have to know about outside components. But, can't we all agree that the web browser is a special case and certainly warrants whatever work needs to be done to fix it? Is it out of the question to think about branching a special version of MSHTML and a special version of JScript specifically for IE that are intimate enough to make this and many other long-standing technical issues be solved?

"I want you all to know that we have been listening and have recently made some great fixes to our engine to improve the garbage collection routine and to reduce unbounded memory growth."

Are you referring to the cyclic COM object reference memory leaks? This probably ties right in with my other comments about possibly tightening the relationship between MSHTML + JScript specifically for the IE product. Coupling the 2 components would certainly bring about solutions to the memory leaks because maybe JScript can inspect COM refcounts (I don't know the internals, I am speculating, anyone who wants to clarify please do). What I do know is that, technical difficulties or not, gigantic memory leaks in IE are holding up large scale client-script driven apps.

re: IE + JavaScript Performance Recommendations - Part 1

Gordon — Thu, 31 Aug 2006 21:22:25 GMT

Uhm, creating a variable called "length" is asking for trouble.

It might not be a reserved word, but it's like poking the devil with a sharp stick and not expecting to get burned.

good to see that JavaScript wasnt forgotten, it would be better if there was improvments on the level of support (DOM features etc.) but capping some of the leaks is also good.

re: IE + JavaScript Performance Recommendations - Part 1

Will — Thu, 31 Aug 2006 21:29:10 GMT

I concur with all that say the reference to document.all should be abandoned. It severely polutes the document object, it is not xbrowser compatible, and therefore leads to bad design.

Have you ever run into code, where the developer created forms called "images", "body", or "links" etc.? Man that makes nightmares.

Please correctly lead the Web development community by posting valid DOM samples, that are xbrowser compatible, and that avoid any reference to proprietary objects/methods.

Notes on the interaction of ClearType with DXTransforms in IE7

IEBlog — Thu, 31 Aug 2006 22:00:25 GMT

Hello again, this is Peter Gurevich, IE PM for ClearType (among other things, as my blog posts have shown).&nbsp;...

re: IE + JavaScript Performance Recommendations - Part 1

Fduch — Fri, 01 Sep 2006 00:43:44 GMT

@Ted
{{
<<I posted some ridiculous parts of IE source code, but moderators censored them. I can post again if anyone wants. >>

1> There's no reason for anyone to believe that your samples are in the product &/or ever were in IE.

2> If you do decide to post copyrighted source code, save Microsoft's lawyers some trouble and post your home address. }}

1) I can't prove that the code is still there, BUT
a) I notice some BAD behavior in IE6
b) I found the source code for that part and it looked BAD
c) IE7 has the same visible behavior, so I assume that this part of code wasn't changed.
2) I don't think that getting my address from my Live ID is big deal for them.

P.S. I am pro IE7. I just REALLY want some issues be finally FIXED.

VBScript

Erik — Fri, 01 Sep 2006 09:24:50 GMT

Are there any improvements in the VBScript engine for IE7?

re: IE + JavaScript Performance Recommendations - Part 1

Chris Breen — Fri, 01 Sep 2006 17:27:35 GMT

> var elementText = BuildTitle() + BuildBody() + BuildFooter();
> document.getElementById(‘target’).innerHTML = elementText;

I my experience I've found that appending the innerHTML of an element rather than manipulating the DOM leaks memory in IE like a leaky sieve.

The function caching is a new idea to me, thanks for that.

re: IE + JavaScript Performance Recommendations - Part 1

Dave Massy [MSFT] — Fri, 01 Sep 2006 21:22:13 GMT

Erik,
There has been no real work done on the VBScript engine for IE7. We expect to focus on cross browser technologies in the future so JavaScript is likely to receive more atention that VBScript moving forward.
Thanks
-Dave

re: IE + JavaScript Performance Recommendations - Part 1

Tino Zijdel — Sat, 02 Sep 2006 02:17:46 GMT

ok, I did some testing myself to verify the tips mentioned in this blogpost.

Test setup:
Machine: AMD XP2000 512MB RAM running Windows 2000 SP4
Browsers tested:
IE6 SP1 (no IE7 for win2k...)
Firefox 1.5.0.6
Opera 9.01

First I tested the tip on caching function-pointers in a local variable:

function bench1()
{
var s = new Date().getTime();

var i = 500000;
while (i--)
{
foo();
}

var e = new Date().getTime();
alert (e-s);
}

function bench2()
{
var s = new Date().getTime();

var i = 500000;
var func = foo;
while (i--)
{
func();
}

var e = new Date().getTime();
alert (e-s);
}

function foo()
{
var a = Math.random();
}

Results:

IE6
bench1: 1282ms
bench2: 1432ms

Firefox
bench1: 2454ms
bench2: 3765ms

Opera
bench1: 982ms
bench2: 841ms

Conclusion: only Opera seems to benefit from this tip, both IE6 and Firefox actually perform worse by 'caching' a global functionpointer in a local variable.

Now for the other tip, caching a reference to a DOM-method on an element:

function bench1()
{
var s = new Date().getTime();

var i = 5000;
var element = document.getElementById('foo');
while (i--)
{
element.appendChild(document.createTextNode('a'));
}

var e = new Date().getTime();
alert (e-s);
}

function bench2()
{
var s = new Date().getTime();

var i = 5000;
var myappend = document.getElementById('foo').appendChild;
while (i--)
{
myappend(document.createTextNode('a'));
}

var e = new Date().getTime();
alert (e-s);
}

Results:

IE6
bench1: 951ms
bench2: 1462ms

Firefox
bench1: 1723ms
bench2: error

Opera
bench1: 160ms
bench2: error

Conclusion: apart from the fact that this sort of construction only seems to work in IE, the 'tip' is actually a lot slower(!)

If you are to append a lot of elements to a certain DOM element I would suggest detaching this containing element from the DOM, appending, and re-attach it again something like:

function bench3()
{
var s = new Date().getTime();

var i = 5000;
var container = document.body.removeChild(document.getElementById('foo'));
while (i--)
{
container.appendChild(document.createTextNode('a'));
}
document.body.appendChild(container);

var e = new Date().getTime();
alert (e-s);
}

Results:

IE6: 800ms
Firefox: 210ms
Opera: 140ms

Furthermore a lot of time can be spent by the evaluation of the condition in a loop:

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

here the length-property needs to be accessed every iteration, this is a big penalty when 'elements' is f.i. a live Nodelist. Much faster variants are:

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

or when order doesn't matter:

var i = elements.length;
while (i--) { }

or even better:

var element, i = 0;
while ((element = elements[i++])) { }

General conclusion: this blogpost belongs in the garbage-bin. It promotes non-standard techniques and the actual 'tips' are worthless.
Note also that IE has an advantage when it comes to rendering DOM-changes; it's renderengine is optimized for speed, not for standards-compliance.
In that light it is pretty interesting to see that Opera 9 outperforms both IE and Firefox by a huge margin.

re: IE + JavaScript Performance Recommendations - Part 1

Tino Zijdel — Sat, 02 Sep 2006 03:11:50 GMT

I tested the above also on my laptop running winXP with IE7RC1 but the results show the same: performance of the 'tips' is actually worse than the 'normal' method, which means that 'caching function pointers' and 'caching DOM methods' is useless.
Caching DOM references however is still a good idea, but I guess everone already knew that...

re: IE + JavaScript Performance Recommendations - Part 1

Tino Zijdel — Sat, 02 Sep 2006 15:28:29 GMT

By the way: when I reference a method on an object and execute that method I expect it to be executed in the global scope; the way that MS seems to have implemented the DOM ECMAScript bindings is completely illogical.

I'm also looking forward to part 2 and 3, I hope they will be as interesting as this article :P

re: IE + JavaScript Performance Recommendations - Part 1

Fduch — Sat, 02 Sep 2006 17:04:01 GMT

pwned :-)

Now I understand why overall perfomance of IE7 is so bad... with half-minute lags sometimes occuring when switching tabs.

re: IE + JavaScript Performance Recommendations - Part 1

AnonL — Sat, 02 Sep 2006 17:57:57 GMT

-

@IE-team: just take a look at benchmark 3 in this comment for a tiny math performance issue. And Love the article by the way, looking forward to later parts.

@Tino and few others:

I Love these quibbling comments of yours Tino! I actually like people with a meticulous sense of fault-finding. Well, there's a downside to it that when people complain a lot, their strictures precision wears off logarithmically. In this particular case, I might pin Peter for his rather ambiguous exposition on the matter which started it all in the first place :) "No explanation of any kind or amount is enough; Ever!" would have been a good memo.

Anyway, for a follow-up to Tino's unprofitable experiment, I've done some of my own, with some interesting results. There's a little misunderstanding in Tino's take on the function caching Peter has stressed on. The point was about functions in places where they're completely out of scope of each other like those cutesy little objects we create in JScript. Below, I've written some over-simplified JS to check them out.

My machine setup: a generic overclocked Intel.
IE6 sp1 on win2k (yep, another old school win2k fan over here!)
FF 1.5.0.6 and Opera 9.01

-------------------------------------------------------

/* Benchmark 1 */

function myObject1()
{
this.get = calculate;
function doSomeDivision(num)
{
return num/1.31415;
}

function calculate(num)
{
var i=300000;
while(i--)
{
num = doSomeDivision(num)+doSomeDivision(2.71828);
}
return num;
}
}

function myObject2()
{
this.get = calculate;
function doSomeDivision(num)
{
return num/1.31415;
}

function calculate(num)
{
var doSomeDivision_pointer = doSomeDivision;
var i=300000;
while(i--)
{
num = doSomeDivision_pointer(num)+doSomeDivision_pointer(2.71828);
}
return num;
}
}

function bench1()
{

var s = new Date().getTime();
var obj1 = new myObject1();
var out = obj1.get(1234567890);
var e = new Date().getTime();
alert (e-s);

//--------------------------------------

var s = new Date().getTime();
var obj2 = new myObject2();
var out = obj2.get(1234567890);
var e = new Date().getTime();
alert (e-s);
}

bench1();

---------------------------------------------------------------------------------------------
Benchmark 1 results:

IE:
(no-cach): 1453
(cached ): 1328
+125ms benefit.

FF:
(no-cach): 2515
(cached ): 2438
+77ms benefit.

Opera:
(no-cach): 406
(cached ): 391
+15ms benefit.

Well, It's clear (to me at least) that the article may have not belonged in the garbage bin as previously thought after all.

By the way, as I was playing with the setup, I found out that we can optimize the code big time if we reference functions to object they belong to (using "this" property).

----------------------------------------------------------------------
/* Benchmark 2 */
function myObject3()
{
this.get = calculate;
function doSomeDivision(num)
{
return num/1.31415;
}
this.doSomeDivision = doSomeDivision;

function calculate(num)
{
var i=300000;
while(i--)
{
num = this.doSomeDivision(num) + this.doSomeDivision(2.71828);
}
return num;
}
}

function bench2()
{
var s = new Date().getTime();
var obj3 = new myObject3();
var out = obj3.get(1234567890);
var e = new Date().getTime();
alert (e-s);
}

bench2();

----------------------------------------------------------------------
Increase in performance is significant especially in FF:

Benchmark 2 results:
IE:
( no-cach ): 1453
(object-ref): 1100
+353ms

FF:
( no-cach ): 2515
(object-ref): 1094
+1421ms!

Opera:
( no-cach ): 406
(object-ref): 406
No difference!

I've no idea what gives about how the way IE and FF look-up system interprets these references that it yields this huge boosts but they definitely enjoy this a lot.

=============

Ok, for some non-relevant performance issues, I found IE (and opera) can use some guess work when dealing with cracked mathematicians:

/* Benchmark 3 */
function bench3()
{
var s = new Date().getTime();
var i = 500000;
while(i--)
{
var num= 1234.12345 / 0;
}
var e = new Date().getTime();
alert (e-s);
}
bench3();

------------------
IE: 391ms, FF:47ms, Opera: 266ms

Anything divided by zero means infinity. A lot of people know this, including FireFox! Yes, this is incredibly stupid setup, but if IE's Jscript people do us a favor and take care of this we might save ourselves from hearing a lot of things like "IE is STUPID dude! FF knows anything divided by zero is infinity but IE has to ask the co-processor every single time; dude."

And for the last test I show you it's not the calculation part that makes the Opera to be the boss here:

/* Benchmark 4 */
function bench4()
{
var s = new Date().getTime();
var i = 500000;
while(i--)
{
var num= Math.sqrt(3.1415);
}
var e = new Date().getTime();
alert (e-s);
}
bench4();

-----------------------------
IE:265ms, FF:718ms, Opera:312ms

It's clear Opera's strength lays in the way its script engine compiles the JS instruction on the air. I'd love to know how they've done that.

===================================================

Conclusion:

A) Although people working at Microsoft may have been some Homo Sapiens descended from some random ape-like creatures which were themselves descended from other nasty things, they make things or write articles that are actually credible most of the time, in contrast with people working in open source holy community which are intelligently designed and make sacred things like FireFox and will rule the world sooner or later.

B) FireFox community could definitely use some members with "I Love to Complain" t-shirt on. IE community is heavily using them right now with lovely results.

C) Opera kicks butt! (In JS arena at least)

Thanks for reading this ~

re: IE + JavaScript Performance Recommendations - Part 1

AnonL — Sat, 02 Sep 2006 21:12:04 GMT

I didn't jump to conclusion about cached DOM methods above until I'm totally sure Tino trash talk was right on the money. Now I'm pretty much sure it was. Excellent job Tino!

Caching function pointers is an unavoidable rule of thumb and I think Peter simply extended this principle to cover DOM methods which backfired with the performance reek Tino glorified above. I reckon the reason might be over-optimization, like double-zipping an already zipped file. I believe IE has already optimized its DOM method access and we have got to avoid overdoing it. Anyway, unless there has been something we totally mistook (or something they're still working on), our Performance PM got some amendment to do about this one.

Interestingly, this whole caching function pointer technique still holds water with custom functions we define on the DOM objects as the article expected:

/* benchmark 5 */
function bench5()
{

var element = document.getElementById('foo').myMethod= function(val){return val/1.000001}

var s = new Date().getTime();
var element = document.getElementById('foo');
var i = 100000; var out = i;
while(i--)
{
out = element.myMethod(out);
}
var e = new Date().getTime();
alert ("Non-cached method: "+(e-s));

//-------------------------------------

var s = new Date().getTime();
var elementAppend_pointer = document.getElementById('foo').myMethod;
var i = 100000; var out = i;
while(i--)
{
out = elementAppend_pointer(out);
}
var e = new Date().getTime();
alert ("Cached method: "+(e-s));
}
bench5();

------------------
IE:
(non-cached):1125
( cached ):203
+922

FF:
(non-cached):141
( cached ):250
-109

Opera:
(non-cached):79
( cached ):62
+17

As I can see, IE definitely needs to reconsider some inner DOM look-up optimizations; With FF we apparently hit the overdoing wall again and Opera rocks as usual.

Keep it up Tino, as I've always said, any community could use some flying brickbats - fair or foolish. Whether your technique is pure pessimism or simply a 'throw enough stuff at the wall' approach, just keep it up.

Thanks again. ~

re: IE + JavaScript Performance Recommendations - Part 1

Tino Zijdel — Sat, 02 Sep 2006 22:42:26 GMT

AnonL: thanks for the heads-up. My sarcasm is actually more an expression of frustration having to deal with IE's quirks, bugs and shortcomings on a daily basis and the fact that that wil not change much with the coming of IE7.

Now for your excellent post on the caching of functionpointers: I still think that in 99% of all cases there will be just one step down in the scopechain to look up some global function, and as my benchmarks show this is only more costly. For the other 1% where this technique actually might improve performance you would have to ask yourself if this 125ms over 300.000 lookups (something you will rarely do in normal code) really makes a difference. As you yourself splendidly demonstrated with your second benchmark (although I would prefer prototyping the methods, especially when you plan to create many of those objects) it makes much more sence to refactor the code in such way that you don't need to do lookups down the scopechain at all, and in production code there are probably far better candidates for optimization than those lookups. In fact, in my experience heavy javascript applications only spent a very small amount of time executing arbitrary javascript code and most of the time repainting and rendering the interface.

re: IE + JavaScript Performance Recommendations - Part 1

Tino Zijdel — Sat, 02 Sep 2006 23:12:39 GMT

AnonL: as for your benchmark no. 5 it must be noted that these 2 methods (cached and non-cached) are not really the same; in the non-cached version myMethod is executed in the scope of the DOM object, in the cached version it is executed in the global scope. I think that would explain the difference in IE where DOM objects are actually COM objects and this interface might just be responsible for the delay.

re: IE + JavaScript Performance Recommendations - Part 1

verdy_p — Mon, 04 Sep 2006 17:54:17 GMT

Isn't there any way for the Javascript engine to fix the way it handles the + operator so that it will be parsed as a list of items to add, then items will be parsed and computed, and the type of the first computed item in the list will indicate how to compute the final operation in the list (concatenation or numeric addition)?
If so, the + operator would no longer be a binary operator evaluated step by step in a chain, but instead would be avaluated by compiling an expression that first takes the sum of the string lengths, allocates a single buffer for the result, and then performs the concatenation with a single copy into that buffer.
Compare this to how Java compiles a String concatenation using an intermediate StringBuffer (before Java5) or an unsynchronized StringBuilder (in Java5+), which gets transfermed into a String object only at end of the concatenations: it is much smarter than IE's implementation of string concatenation in JavaScript, and a lot faster because it saves many reallocations. This is especially important when generating complex strings with many items, such as the string to assign to an .innerHTML property of a document or <div> container, with many items concatenated with +.

Of course this won't resolve the case of the += operator used many times. For this issue, one must use an heuristic like the one used in Java's StringBuffer or StringBuilder, that allocates space with an heuristic for possible extensions: the extra space may be freed only when converting it to the final non-mutable String, if this really saves enough bytes, or if there's a system in the Garbage Collector that allows freeing asynchronously the extra unused space at end of non-mutable arrays and buffers (like the "string" object backing store buffers); but this may require changing the objects allocation descriptors (with a way to specify the effectively used length and to mark the mutable status), so may be a lot of work in the GC implementation (this is not needed in Java because it natively differentiates the backing store of arrays from simple fixed-size objects, so the length of arrays and the mutable status has always been part of the internal representation, also because Java uses multiple heaps for arrays and for fixed-size objects, to speed up the GC and the reuse of freed objects in the fixed-size heaps, without needing multiple moves for the same objects when compacting the heap free space).

I really hope that IE's implementation of the Javascript GC will continue to be improved (because the current memory usage of IE is still too large, and its GC is extremely slow to reclaim the unused memory into a much smaller heap with faster data locality that performs much better with the processor cache and the extra slow virtual memory committed to disk).

re: IE + JavaScript Performance Recommendations - Part 1

verdy_p — Mon, 04 Sep 2006 18:26:45 GMT

why not compiling:
"a" + b + "c" + d
as if it was:
["a", b, "c", d].join("")
except that it would be using an intrinsic method (non-overridable, except if IE provides a way to override operators like in C++, something that is external to ECMAScript design), without parameter, that checks the datatype of the first element of the array to determine if this is concatenation or concatenation instead of a function lookup for join, something like:
["a", b, "c", d]."__plus__"()
This way of compiling would be prefered if there are more than 2 elements in the array (otherwise the array construction will just loose time needlessly)

re: IE + JavaScript Performance Recommendations - Part 1

Tino Zijdel — Tue, 05 Sep 2006 00:38:56 GMT

verdy_p: are you seriously suggesting that Microsoft should change it's ECMAScript implementation (which is a standard) to something non-standard?
Are you one of those people that think that Javascript should be more like Java? or Python? or Ruby? It's not, get over it and deal with it.

The 'problem' with the + operator being used both as an arithmic operator and a string operator depending on the operands is something that only folks novice to Javascript seem to have problems with. Now I'm not saying that you are a complete n00b when it comes to Javascript but I'm sure you will understand that changing some fundamental behavior in a language that has been widely used for years is something that simply cannot be done, and surely not just by one party - Microsoft still has enough work to do fixing those areas that still aren't compliant to existing specifications and standards.

re: IE + JavaScript Performance Recommendations - Part 1

Nigel Moore — Wed, 06 Sep 2006 14:27:50 GMT

Good article, but the comments wre more enlightening!

I'm looking forward to part 2!

re: IE + JavaScript Performance Recommendations - Part 1

AnonL — Thu, 07 Sep 2006 17:42:13 GMT

-

I'm late again. In case someone is still following this comment threads...

@Tino:
Just to sort out my conclusion on the DOM function referencing, I might say it is basically a pretty bad idea to start with. About benchmark 5 above, I don't think the scope change - although been drastic and convincingly an erratic behavior - is the main reason behind browser's better performance, evidently it's simply more a cached pointer at work. Concerning real DOM functions, well, they turned out to be no cutesy cuddly objects at all. No browser gives you a function pointer on DOM method inquires. Apparently when we try to do so, they retrieve a pointer to an alien Object that is itself cloned from the DOM interface. That's where we draw a line between JavaScript playground and browser interior structures. They simply don't fraternize. I tried to loop through (using "for...in") one of those mutations which crashed mshtml.dll out of IE. FF simply tosses a dead non-native Object. I guess IE's COM implantation still allow the object to do its job at the expense of performance downgrades and irregularities like that ugly crash.

Just a simple note to myself:
* * * * * * * * * * * * * * * * * * * * * * * * * *
"No funny business with DOM methods".

* * * * * * * * * * * * * * * * * * * * * * * * * *

And about that frustration part, I think all these people commenting here would give you an "I've been there" monologue of their own labor. Personally I imagine I've relocated my high expectations to IE8 long ago; just to keep my calm. Or sanity.

You just keep yourself buckled down for coming parts of this article.

Thanks ~

re: IE + JavaScript Performance Recommendations - Part 1

vasso zahuidze — Sun, 10 Sep 2006 09:18:22 GMT

windos sucks

Petits articles interessants pour dveloppeurs web...

blog.virgule.info — Wed, 13 Sep 2006 01:35:53 GMT

Quelques articles rcents que tout dveloppeur web devrait lire...

Map the Maps! » Blog Archive » IE7 bien plus performant en Javascript - aussi bien que Firefox 1.5!

Thu, 14 Sep 2006 16:27:48 GMT

PingBack from http://www.mapthemaps.com/blog/?p=19

Hello World!

Kaushik's JavaScript Weblog — Fri, 15 Sep 2006 19:32:57 GMT

My name is Kaushik. I am a developer on the JavaScript team at Microsoft.
I’ll be blogging mostly about...

Points of interest #4

John Mandia — Fri, 15 Sep 2006 23:50:17 GMT

End of the week points of interest:New York Times are working on a WPF tool to improve readability :

ScriptTeaser » Blog Archive » Script Optimization

ScriptTeaser » Blog Archive » Script Optimization — Sat, 16 Sep 2006 19:46:09 GMT

PingBack from http://scriptteaser.com/learningjavascript/script-optimization/

Microsoft JavaScript Perf. Tips > Archives > Web 2.0 Stores

Microsoft JavaScript Perf. Tips > Archives > Web 2.0 Stores — Sun, 17 Sep 2006 00:33:54 GMT

PingBack from http://web2.0stores.com/blog/archives/microsoft-javascript-perf-tips/

???????? ?????????????????????????? » Blog Archive » Java Script Performance Recommendations

Tue, 19 Sep 2006 08:16:31 GMT

PingBack from http://globallist.ru/?p=10

Ajax Links

Stuart Jones Weblog — Tue, 19 Sep 2006 19:19:52 GMT

Here are some websites that I referenced during my Ajax talk as well as other sites that provide useful...

Ajax Links

Stuart Jones Weblog — Tue, 19 Sep 2006 23:34:42 GMT

Here are some websites that I referenced during my Ajax talk as well as other sites that provide useful...

IE7 JavaScript Improvements - The Web Standards Project

IE7 JavaScript Improvements - The Web Standards Project — Thu, 21 Sep 2006 18:09:35 GMT

PingBack from http://www.webstandards.org/2006/09/21/ie7-javascript-improvements/

Dijital World » Notes on the interaction of ClearType with DXTransforms in IE7

Dijital World » Notes on the interaction of ClearType with DXTransforms in IE7 — Fri, 29 Sep 2006 20:20:55 GMT

PingBack from http://www.aesjkt.com/wp/?p=1801

Dijital World » IE + JavaScript Performance Recommendations - Part 1

Dijital World » IE + JavaScript Performance Recommendations - Part 1 — Fri, 29 Sep 2006 20:23:34 GMT

PingBack from http://www.aesjkt.com/wp/?p=1808

Zen Thoughts : IE + JavaScript Performance Recommendations - Part 1

Zen Thoughts : IE + JavaScript Performance Recommendations - Part 1 — Mon, 02 Oct 2006 08:09:07 GMT

PingBack from http://www.zhen.org/blog/?p=202

IrishDeveloper.com » Blog Archive » Javascript performance tips from the IE7 folks

Fri, 06 Oct 2006 18:17:29 GMT

PingBack from http://www.irishdeveloper.com/ie7/javascript-performance-tips-from-the-ie7-folks/

Jim Zimmerman - How to make your javascript run faster in IE

Jim Zimmerman - How to make your javascript run faster in IE — Sat, 07 Oct 2006 09:26:50 GMT

PingBack from http://www.jimzimmerman.com/DasBlog/2006/08/29/How+To+Make+Your+Javascript+Run+Faster+In+IE.aspx

Fat agnus » Blog Archive » While we wait for Firefox 2 and IE7

Fat agnus » Blog Archive » While we wait for Firefox 2 and IE7 — Tue, 10 Oct 2006 21:24:05 GMT

PingBack from http://fatagnus.com/while-we-wait-for-firefox-2-and-ie7

??????????????? v2 » Blog Archive » [??????]060714 ~ 060909 ??? keep new

??????????????? v2 » Blog Archive » [??????]060714 ~ 060909 ??? keep new — Mon, 30 Oct 2006 04:47:07 GMT

PingBack from http://blog.flymok.net/2006-09-10/167

IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies

IEBlog — Fri, 17 Nov 2006 01:36:56 GMT

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

JavaScript performance - access to global variables [part 1]

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

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

simple singularities » javascript optimization

simple singularities » javascript optimization — Sat, 18 Nov 2006 04:00:11 GMT

PingBack from http://fri13th.com/blog/archives/209

References « Tree Menu Development

References « Tree Menu Development — Tue, 21 Nov 2006 19:55:42 GMT

PingBack from http://dmtreemenu.wordpress.com/2006/11/18/references/

Crisp’s blog » Blog Archive » Beware of premature optimization

Crisp’s blog » Blog Archive » Beware of premature optimization — Wed, 29 Nov 2006 01:15:43 GMT

PingBack from http://therealcrisp.xs4all.nl/blog/2006/11/28/beware-of-premature-optimization/

Compression et obfuscation des fichiers JavaScript avec Atlas

Atteint de Javascriptite aigüe — Mon, 18 Dec 2006 02:44:52 GMT

Lorsque j'avais examiné les fichiers JavaScript de Microsoft Ajax Extensions beta 1 une question m'était

Responses for Benchmark Anomalies Noted by our Community Members!

Justin Rogers [MSFT] — Wed, 03 Jan 2007 20:12:53 GMT

@Tino

I'd like to respond to Tino's comments on some of the optimizations. Yes, we know that in some cases the optimizations aren't optimal for other browsers. We are trying to provide insight in to making IE faster and each of these samples has not been fully tested in FireFox or Opera. With that in mind, lets take a quick look at the three benchmarks that were performed which contradict the article.

Your first benchmark is spot on. Your scenario was much simpler than most. There was nothing polluting the global namespace and there was only a single level of scope. So caching global function pointers in your sample produced a slower result. When you are looking at much larger sites, or mash-ups, where script is pulled in from many sources then the caching of script engine based function pointers begins to win. If you add in deep scope chains, caching the global function pointer also begins to be faster. We know that the performance gain in this space is minimal. Our main recommendation is to cache DOM function pointers, which I'll explain next.

Your second benchmark points out DOM function pointers as coming out slower. This is not the case. A DOM method call from the script engine requires a name to ID look-up, followed by an invoke using that ID. When you've cached the method we wrap it in a special function object that already knows the ID to invoke on and so it performs a quicker invoke, by about 15%. I believe your scenario may have fallen prey to the operations being performed. At the end of this comment I've added a code sample that shows getElementById (caching this function) to be faster by about 15%. Please feel free to run the numbers by yourself. Note, care was taken not to allow the JavaScript GC and other functionality of the system to affect the timing of the calls. The sample where many text nodes were being created and appended falls prey to these systems and provides inaccurate results.

@AnonL

You had some script where you attached a JScript function as an expando on a DOM element. Then you cached this guy off to use it. This is a perfect example of when caching really comes in for a huge win. Glad you pointed it out. It is a shame that all of the combinations of different types of objects being shared between IE and the JScript have different performance. This is a by-product of supporting any IActiveScript language. After all, IE does work perfectly well with PerlScript, VBScript, PythonScript, and many other script engines today and so a lot of code remains to support those engines.

Someone noted that an enumerator on top of a cached DOM function would result in a crash. You'll be happy to know that this was fixed in IE 7.

@Code Sample for cached DOM function pointer benchmark - Note: Tested on IE 7 to be about 15% faster.

function bench1()

{

var s = new Date().getTime();

var i = 25000;

while (i--)

{

document.getElementById('foo');

}

var e = new Date().getTime();

alert (e-s);

}

function bench2()

{

var s = new Date().getTime();

var func = document.getElementById;

var i = 25000;

while (i--)

{

func('foo');

}

var e = new Date().getTime();

alert (e-s);

}

</script>

<button onclick="bench1();">Bench 1</button>

<button onclick="bench2();">Bench 2</button>

IE+JScript Performance Recommendations Part 3: JavaScript Code Inefficiencies

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

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

Notes on the interaction of ClearType with DXTransforms in IE7

Notes on the interaction of ClearType with DXTransforms in IE7 — Thu, 11 Jan 2007 13:06:00 GMT

PingBack from http://www.anasayfa.org/wp/?p=2560

Some JavaScript Links To Chew On

K. Scott Allen — Wed, 17 Jan 2007 08:02:26 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:17 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:30 GMT

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

Learning the World » Website Performance Tweaks

Learning the World » Website Performance Tweaks — Fri, 26 Jan 2007 00:39:25 GMT

PingBack from http://learningtheworld.eu/2007/performance/

LeoTech » Blog Archive » Javascript Smorgasboard

LeoTech » Blog Archive » Javascript Smorgasboard — Thu, 08 Feb 2007 23:42:48 GMT

PingBack from http://lpetr.org/blog/archives/javascript-smorgasboard

IE und JavaScript Performance Empfehlungen

Mon, 12 Feb 2007 14:58:42 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:06 GMT

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

The Emotional Pumpkin » Talking shop: IE and JavaScript performance

The Emotional Pumpkin » Talking shop: IE and JavaScript performance — Thu, 08 Mar 2007 02:09:25 GMT

PingBack from http://www.blogs.ravasthi.name/tepumpkin/2007/03/07/talking-shop-ie-and-javascript-performance/

NathanSwart.com » Blog Archive » links for 2007-03-16

NathanSwart.com » Blog Archive » links for 2007-03-16 — Fri, 16 Mar 2007 05:17:22 GMT

PingBack from http://nathanswart.com/2007/03/15/links-for-2007-03-16/

Grokking JavaScript Variables « The Curious Schemer

Grokking JavaScript Variables « The Curious Schemer — Tue, 20 Mar 2007 16:27:20 GMT

PingBack from http://rayfd.wordpress.com/2006/11/02/grokking-javascript-variables/

?????????????????? ???????????? » Blog Archive » [JS] IE??? JavaScript ?????? ????????? ???

Mon, 17 Sep 2007 09:43:33 GMT

PingBack from http://mygony.com/archives/1184

Fine Art » IEBlog : IE + JavaScript Performance Recommendations - Part 1

Fine Art » IEBlog : IE + JavaScript Performance Recommendations - Part 1 — Thu, 27 Sep 2007 00:46:47 GMT

PingBack from http://fineartz.info/ieblog-ie-javascript-performance-recommendations-part-1/

Improve JavaScript performance

Improve JavaScript performance — Fri, 12 Oct 2007 07:50:40 GMT

PingBack from http://efficienttips.com/improve-javascript-performance/

Optimiser vos boucle for avec JavaScript

Atteint de Javascriptite aiguë [Cyril DURAND] — Sun, 16 Dec 2007 18:04:25 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:05 GMT

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

Ron Cundiff, on IIS7, and other Web Development Best Practices

Out Of The Box — Wed, 16 Jan 2008 23:20:14 GMT

Last night, Ron presented to the Memphis .NET Users Group .  The talk began with the improved administrative

Ron Cundiff, on IIS7, and other Web Development Best Practices

Noticias externas — Thu, 17 Jan 2008 00:10:10 GMT

Last night, Ron presented to the Memphis .NET Users Group .  The talk began with the improved administrative

MSDN Blog Postings » Profiling JavaScript With Ajax View Tool: Spot Poor Performance Client Script In No Time

Thu, 17 Jan 2008 08:44:51 GMT

PingBack from http://msdnrss.thecoderblogs.com/2008/01/17/profiling-javascript-with-ajax-view-tool-spot-poor-performance-client-script-in-no-time/

Mellow Morning » Javascript optimization - high performance JS apps

Mellow Morning » Javascript optimization - high performance JS apps — Sun, 18 May 2008 22:49:55 GMT

PingBack from http://www.mellowmorning.com/2008/05/18/javascript-optimization-high-performance-js-apps/

JEDI » Blog Archive » Is your Jquery or Javascript getting Slow or bad Performance ?

Fri, 10 Oct 2008 16:09:59 GMT

PingBack from http://www.jedi.be/blog/2008/10/10/is-your-jquery-or-javascript-getting-slow-or-bad-performance/

JEDI » Blog Archive » Is your Jquery or Javascript getting Slow or bad Performance ?

Fri, 10 Oct 2008 16:09:59 GMT

PingBack from http://www.jedi.be/blog/2008/10/10/is-your-jquery-or-javascript-getting-slow-or-bad-performance/

AJAX Performance Bestpractices

Gaurav Seth's WebLog — Sat, 22 Nov 2008 00:01:43 GMT

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

Do only what matters: Javascript Articles

Do only what matters: Javascript Articles — Sat, 22 Nov 2008 05:10:59 GMT

PingBack from http://khaidoan.wikidot.com/javascript-articles

JavaScript?????????????????? | ????????????

JavaScript?????????????????? | ???????????? — Thu, 22 Jan 2009 04:00:53 GMT

PingBack from http://qingbo.org/archives/577.html

MS radzi jak pisac wydajny JScript dla IE - jak to sie ma do JavaScriptu i przegl?darek? | hilpers

Fri, 23 Jan 2009 06:47:35 GMT

PingBack from http://www.hilpers.pl/232781-ms-radzi-jak-pisac-wydajny

JavaScript profiling in Internet Explorer « Really Aced

JavaScript profiling in Internet Explorer « Really Aced — Fri, 06 Mar 2009 14:26:36 GMT

PingBack from http://reallyaced.wordpress.com/2009/03/06/javascript-profiling-in-internet-explorer/

Coding style » Blog Archive » Quelques optimisations en JS

Coding style » Blog Archive » Quelques optimisations en JS — Tue, 31 Mar 2009 10:04:46 GMT

PingBack from http://www.codingstyle.fr/2009/03/26/quelques-optimisations-en-js/

Web Development Tips, Tricks & Trivia » Blog Archive » HOW TO improve the front-end performance of a website

Wed, 27 May 2009 14:28:28 GMT

PingBack from http://webdevelopment.mobiforumz.com/2008/01/02/how-to-improve-the-front-end-performance-of-a-website/

IEBlog IE JavaScript Performance Recommendations Part 1 | Paid Surveys

IEBlog IE JavaScript Performance Recommendations Part 1 | Paid Surveys — Fri, 29 May 2009 22:17:42 GMT

PingBack from http://paidsurveyshub.info/story.php?title=ieblog-ie-javascript-performance-recommendations-part-1

IEBlog IE JavaScript Performance Recommendations Part 1 | Wood TV Stand

IEBlog IE JavaScript Performance Recommendations Part 1 | Wood TV Stand — Wed, 03 Jun 2009 03:23:10 GMT

PingBack from http://woodtvstand.info/story.php?id=84076

IEBlog IE JavaScript Performance Recommendations Part 1 | Portable Greenhouse

IEBlog IE JavaScript Performance Recommendations Part 1 | Portable Greenhouse — Wed, 03 Jun 2009 11:11:39 GMT

PingBack from http://portablegreenhousesite.info/story.php?id=31938

IEBlog IE JavaScript Performance Recommendations Part 1 | Weak Bladder

IEBlog IE JavaScript Performance Recommendations Part 1 | Weak Bladder — Mon, 08 Jun 2009 04:21:25 GMT

PingBack from http://weakbladder.info/story.php?id=6263

IEBlog IE JavaScript Performance Recommendations Part 1 | Green Tea Fat Burner

IEBlog IE JavaScript Performance Recommendations Part 1 | Green Tea Fat Burner — Mon, 08 Jun 2009 05:28:23 GMT

PingBack from http://greenteafatburner.info/story.php?id=1217

IEBlog IE JavaScript Performance Recommendations Part 1 | Outdoor Decor

IEBlog IE JavaScript Performance Recommendations Part 1 | Outdoor Decor — Sun, 14 Jun 2009 01:11:15 GMT

PingBack from http://outdoordecoration.info/story.php?id=3282

IEBlog IE JavaScript Performance Recommendations Part 1 | alternative dating

IEBlog IE JavaScript Performance Recommendations Part 1 | alternative dating — Wed, 17 Jun 2009 10:32:05 GMT

PingBack from http://topalternativedating.info/story.php?id=7296