Thursday, January 4th, 2007

Microsoft IE JavaScript Perf. Tips, Part Trois

Category: IE, JavaScript, Microsoft

In August and November, we highlighted parts one and two of the IE team’s JScript performance tips. Peter Gurevich is back for part three:

  1. Avoid Closures if Possible. What happens when [a closure registered as an event listener] never fires? We expect it to, but it might not. If it doesn’t fire, the closure [may have] a reference to [a] source object and the source object back to the closure. This is an implicit circular reference, hard to spot, and IE leaks memory. This is never good for performance.
  2. Don’t use Property Accessor Functions. A common technique in object oriented programming is to use property accessor functions… in the form of [get/set]_PropertyName (or many others depending on the style)… [This makes for] terrible JScript.

Posted by Ben Galbraith at 11:54 pm
11 Comments

++---
2.6 rating from 44 votes

11 Comments »

Comments feed TrackBack URI

The MS article itself is of questionable value, urging programmers to create “funky” scripting to satisfy IE’s poor implementation of javascript / dom / whatever. General articles on creating high quality scripting would be of much greater value to the community, and might even get MS some respect from the community.

The comments on the article on the other hand are hilarious!

Comment by Morgan Roderick — January 5, 2007

Microsoft has a hilarious politic. They are proud for JScript, but they recommended some of very strange. Why I can not use object oriented programming like get and set? Are they crazy! So, come back to QuickBasic…

Comment by Giovambattista Fazioli — January 5, 2007

Judging from the quality of the article code samples (1, 2, and 3), the IE Team choose the wrong guy for this series of articles.

Comment by Jack Slocum — January 5, 2007

from the article:

“perfCar.m_tireSize = iTireSize + 1; // An upgrade”
// [is preferable over]
function Car_put_tireSize(value){
this.m_tireSize = value;
}
ooCar.SetTireSize(iTireSize + 1); // An upgrade

… and in the example of how things “should” be done:

PrototypeCar.prototype.GetTireSize = function() { return this.m_tireSize; };
PrototypeCar.prototype.SetTireSize = function(value) { this.m_tireSize = value; };
// …
protoCar.SetTireSize(protoCar.GetTireSize() + 1)

I love it!

Comment by Mark Kahn — January 5, 2007

What’s funny is that the first and second tips are the same. The property accessors defined in the constructor are slower because they are closures.

Comment by Dean Edwards — January 5, 2007

Wow, if I don’t use closures I might as well not right code at all. It’s good to know where the inefficiencies are though.

Comment by Adam Sanderson — January 5, 2007

I don’t know what’s more embarrassing for the JScript team: they their interpreter and its assumptions are this broken or that they’re not ending each of these articles with an apology to the world.

If they were to be really honest with us, each of these would begin with “we’re sorry we screwed up this badly, but it’s deployed and that’s just how it is for now. Here’s what you can do about it…”.

That the article includes the sentence “Closures (…) are both extremely powerful and extremely dangerous” should be the tip off to everyone that the problem isn’t with our code, it’s with their engine. They may as well be telling people not to write OO code at all.

C’mon MS. You can, and should, do better.

Regards

Comment by Alex Russell — January 6, 2007

Unless MS fix their terribly slow DOM all their “performance tips” are irrelevant. Any optimization starts with analysis, afterward the slowest parts of system are fixed. In case with MSIE the only optimization possible is to not use MSIE or stick with innerHTML for another 5-7 years till MS will understand the need to buy someone’s else HTML rendering engine.

VS

Comment by Valery Silaev — January 8, 2007

@Alex Russell
—88—-

Can’t stress this more. Just imaging same sentece from authors of Scheme or Haskell interpreter: “Tail recursion are both extremely powerful and extremly dangerous” :))

VS

Comment by Valery Silaev — January 8, 2007

IE code fix:
if(isIE){
alert(“please download firefox”)
return true;
}
//problem solved!!!

Comment by Donald Duck — January 8, 2007

A properly implemented garbage collector can collect closures without any problems whatsoever.

Comment by Klaus — January 9, 2007

Leave a comment

You must be logged in to post a comment.