JScript Blog : JScript Performance IE

Native JSON Support in IE8 and Tracking the ECMAScript Fifth Edition Draft Specification

GauravS — Mon, 22 Jun 2009 22:17:00 GMT

Internet Explorer 8 was the first browser to introduce native support for encoding and decoding JSON. While we were finalizing the JSON support to be introduced in IE8, the ECMAScript Fifth Edition (ES5) Draft Specification was still under active development.

At that time, there were clearly two options in front of us:

First, to wait till the new specification is approved so that we can ship a fully compliant native JSON feature. This had a big disadvantage of not being able to provide web developers with both – performance and security benefits that native JSON offers over a script implementation of JSON in IE8 (as final approval of the standard was at least a year away).

Second, providing JSON support in IE8 based upon early drafts of the standard and then, if necessary, bringing the IE JSON support into compliance with the ES5 specification once the standard is ratified (currently expected to happen in Dec’09). This option had the disadvantage that if the specification changed after IE8 shipped there would be a period time during which the IE8 JSON support would have variances from the ES5 specification.

Weighing the two, we decided to choose the second option as it meant providing web developers the ability to start taking advantage of the native JSON constructs immediately. Moreover, the changes that were expected in the specification were not drastic and could easily be detected and worked around as needed by providing simple wrappers created in JScript itself.

Both, the candidate draft of the ES5 Specification and IE8 are now available. The list of differences that currently exist between the implementation and the draft specification is provided below with possible workarounds. It is worth noting that additional changes may still be made to the candidate ES5 specification based upon reviewer feedback. What this means is that the final form factor of JSON might be a bit different than the draft or what is covered in this article by the time ES5 is standardized.

Following is a list of differences between IE8’s behavior and the current ES5 Draft Specification of

JSON.stringify(value[,replacer[,space]])

If value is undefined and is not replaced using a replacer function, stringify should return undefined instead of the string "undefined".
If value is a function and is not replaced using a replacer function, stringify should return the value undefined rather than the string "undefined".
If value is a Number or String object after the toJSON() method and replacer function have been executed on value, stringify should return the primitive number or string value stored in the Number or String object. Note: Per the latest ES5 errata (27 May’09) Boolean objects are also included in this.
If value is a cyclic object or array, stringify should throw a TypeError and not an Error.
If replacer is not a Function or an Array, stringify should ignore the replacer parameter and not throw an error.
If the replacer function calls a DOM method and passes the key parameter to the same, stringify should not throw an Error. Note: To work around this issue, use key.toString() when passing key to DOM methods like alert() and createElement() inside the replacer function.
If space is an empty string, stringify should default space to an empty string instead of newline.
If space is a Number object or a String object, stringify should use the primitive value of the objects instead of ignoring the same.
If space is set to a value greater than 100, stringify should default space to be 100 instead of the current maximum limit of 65535 after which space is defaulted to 0. Note: Per the latest ES5 errata (27 May’09) the max space should be defaulted to 10.
If space is a non integer numeric value, stringify should default space to be the integer part of the space value instead of defaulting it to the ceiling value of the space argument.

JSON.parse (text[, reviver])

If text contains control characters other than TAB, CR, or LF, throw a Syntax Error. In addition, throw a SyntaxError if TAB, CR, or LF appear in a JSON string literal. IE8 correctly rejects illegal characters outside of string literals. Note: To work around this problem for string literals, user can define a reviver method that looks for string values containing control characters. Given the performance tradeoff to find these characters in all JSON text strings, a generic reviver is not provided in the sample below.

Date.prototype.toJSON (key)

If the Date value is not a finite Number, toJSON should return null

Note that the majority of these differences concerning the handling of invalid argument values or other unusual situations. Most of them have no impact on the encoding or decoding of normal data.

A workaround for these differences is provided in the following patchJSON function which can be called to suitably modify the built-in JSON support methods, before using any of the JSON built-ins by a user. It places a wrapper around the built-in JSON functions.

function patchJSON() {
    // Check if JSON exists, or if
    // JSON has already been patched or updated
    if ((!this.JSON) || (JSON.stringify(undefined) !== 'undefined'))
        return false;  //JSON has already been patched or updated;
    var builtinStringify = JSON.stringify;
    JSON.stringify = newStringify;
    // Date.prototype.toJSON returns null for Dates with a non finite value
    var origDateToJSON = Date.prototype.toJSON;
    if ((origDateToJSON.toString()) ===
    "\nfunction toJSON() {\n    [native code]\n}\n") {
        Date.prototype.toJSON = function(value) {
            if (isNaN(this.valueOf())) return null;
            else {
                return origDateToJSON.call(this, value);
            }
        }
    }
    return true;
    function newStringify(value, replacer, space) {
        // Return undefined when value parameter is undefined
        // or when toJSON exists and returns undefined
        if ((value === undefined) && !(replacer)) return undefined;
        if (value && typeof value === 'object' &&
                typeof value.toJSON === 'function' &&
                !replacer && value.toJSON("") === undefined)
            return undefined;
        // Return undefined when value paramenter is a function
        if ((typeof value === "function") && !(replacer)) return undefined;
        // Ignore the replacer and do not throw an error if the replacer 
        // is not a function or array.
        if (replacer && (typeof replacer !== "function")
            && !(replacer instanceof Array))
            replacer = null;
        if (space !== undefined) {
            // Treat empty string as no space
            if (space === "") space = 0;
            else if (typeof space === "object") {
                // If space is a Number object or String object 
                // use it's primitive value
                if ((space instanceof Number) || (space instanceof String))
                    space = space.valueOf();
                // Ignore objects other than Number and Strings
                else space = 0;
            }
            // If space is set to a value greater than 10, space should be 
            // defaulted to 10. If space is not integral, use the floor value
            // If space string has a length greater than 10, 
            // space should be defaulted to first 10 characters
            if (typeof space === "number") space = Math.min(10,
                Math.floor(Math.abs(space)));
            else if (typeof space === "string") {
                if (space.length > 10)
                    space = space.slice(0, 10);
            }
            else space = 0;
        }
        // Return primitive number, string or boolean value stored
        // in the Number, String or Boolean object
        function newReplacer(key, value) {
            // Execute the replacerand get it's return value
            var tmpValue = replacer.call(this, key, value);
            // If value is a Number or String or Boolean object 
            // use its primitive value
            if (typeof tmpValue === "object") {
                if ((tmpValue instanceof Number) || (tmpValue instanceof String) ||
                (tmpValue instanceof Boolean)) tmpValue = tmpValue.valueOf();
            }
            return tmpValue;
        }
        try {
            // Check if the replacer returns undefined or a function
            // If it does, return undefined
            var tmpValue = value;
            if (replacer && typeof replacer === "function") {
                tmpValue = newReplacer.call({ "": tmpValue }, "", tmpValue);
                if ((tmpValue === undefined) ||
                (typeof tmpValue == 'function')) return undefined;
                return builtinStringify(value, newReplacer, space);
            }
            else return builtinStringify(value, replacer, space);
        }
        // Throw a Type Error if value is a cyclic objects
        catch (e) {
            var replacementException = e;
            if (e.number === -2146823254) {
                replacementException = new TypeError();
                replacementException.description = e.description;
                replacementException.message = e.message;
                replacementException.number = e.number;
            }
            throw replacementException;
        }
    }
}

Because the above patch primarily deals with errors that arise from improperly calling the JSON functions it is most useful while you are debugging your code. When you code is ready for production you may not need to use.

Note: Apart from the above differences due to the changes in the ES5 draft specifications for JSON, there is a known issue which currently exists for IE8. The details of the same along with the possible workarounds are covered in this blog post.

In case you will like to follow the discussions by the TC39 members around how the standard is taking shape, and the discussion around the changes for JSON, you can refer the discussion archives here. The latest ES5 drafts are available at the ECMAScript wiki.

Gaurav Seth, Program Manager, JScript

Internet Explorer 8 Release Candidate Now Available

GauravS — Mon, 26 Jan 2009 23:50:00 GMT

Internet Explorer 8 Release Candidate Is Now Available.

Here is post that would help you Upgrade to Internet Explorer 8 Release Candidate 1.

Note: The comments on this blog are blocked. Pl post your comments on the IE team blog, so that they can be collated at one place.

Gaurav Seth

Program Manager

JScript Team

GC Improvements in JScript for Internet Explorer 8 Beta 1

JSBlog — Wed, 23 Apr 2008 15:56:52 GMT

Hello Friends,

Today I am going to talk about some of the Garbage Collector improvement we have done. Actually the original fix was done in Script 5.7 (shipped with IE7/Vista and also available on down level platforms), which we further enhanced in JScript shipped with IE8 Beta1.

So if you have gone through the Eric’s post on JScript Garbage Collector, you must have noticed following lines…

“Actually what we do is keep track of the number of strings, objects and array slots allocated. We check the current tallies at the beginning of each statement, and when the numbers exceed certain thresholds we trigger a collection. “

…

“However, there are some down sides as well. Performance is potentially not good on large-working-set applications”.

The three thresholds he talked about were fixed in previous versions of JScript. After each GC cycle, counters were reset to zero. Next time when they hit the thresholds, again GC was triggered and so on.

This was alright for small scripts as they never create lot of strings and objects and don’t take much time to execute. But in modern AJAX applications, lots of objects /strings/array entries are created and they live for long enough time. Since rate of object/string/array entry creation is too high in these applications, thresholds are hit quite often, GC is triggered but not able to collect anything because things are still alive and there is no garbage. Counters are reset, but within few statements they again hit the thresholds. GC is triggered again but very less is collected and so on.

So as you see, GC is not able to collect significantly, however it is triggered at fixed intervals (as thresholds are fixed). Each GC cycle proves to be costlier than previous one as more objects have been created since last GC cycle happened.

So to fix this problem, we made the three thresholds adaptive. After each GC cycle, we check if GC was profitable or not, meaning significant collection happened or not. If it was not, then we double the thresholds. If it was, then the thresholds are not changed. Obviously there is an upper bound on value of thresholds, beyond which they are not doubled even if GC cycle was not profitable. Also if GC cycle collected everything, thresholds are set to their initial values.

That’s it for now. Hope you enjoyed reading it.

-JP

Insight into String Concatenation in JScript

janakiram.msv — Wed, 19 Mar 2008 13:35:00 GMT

Hello Friends,

Have you read my post on the String Concatenation issue? If yes, then I can sense your curiosity to know a little bit more about what went on behind the scenes. For example, what is the new algorithm used to get to the performance results projected in the blog, what were the issues faced, how tough/easy it was to implement etc. etc. Well, I didn’t talk much about all these last time as we were still testing the fix and things were not stable at that point of time. But now since IE8 Beta is out and you are already running it on your box (if not, install from here) and loving it J, why not talk a little bit more and try to get few of the queries answered.

In the new implementation, which is running on your box if you are reading this in IE8, we don’t produce actual regular string for each append operation anymore. Instead, we keep the information about all strings which took part in the append operation. The production of actual regular string is deferred for later point of time.

Let’s apply it on the same example I used in the previous blog post…

resultStr = “Jscript” + “String” + “Append” + “problem”

In the previous implementation, we used to produce the actual string and store it in the resultStr. In the current implementation, resultStr points to a structure (let’s call it pseudo-string), which keeps the details like what all strings are needed to produce actual string and in which order.

The logic looks simple. However there were few issues we faced while implementing it, which I think are worth sharing here…

When to Convert pseudo-string back to actual String – As Eric mentioned in his blog, their ‘Fancy-String’ implementation was heavy as they had to convert ‘Fancy–Strings’ back to regular string every time one is passed by variable reference. We also had this big question facing us – ‘When to convert pseudo-strings back to regular strings’? Should it be done as soon as ‘pseudo-string’ has grown to certain size or should it be done soon after append operation is done? Or should it be done when it is passed by variable reference? We evaluated all these approaches but none of them seemed to be giving the kind of gains we wanted. Later we thought why not defer the conversion to the point when pseudo-string can’t serve the purpose and we have to have the regular string. In other words, do the conversion only when actual regular string is needed. For example do the conversion when a ‘subStr’ or ‘trim’ operation is performed on the ‘pseudo – string’ or when the pseudo string needs to be passed somewhere out of the engine, like IE or VBScript, that doesn’t understand pseudo-strings. We tried it and yes, with this, we hit bulls-eyeJ.

Multiple References to single Pseudo-String

If there are multiple references to a single ‘pseudo-string’, then we want to do the conversion only once. For example…

X = “Hi” + “Microsoft”;

Y = X;

Z= X;

In this example X, Y and Z are pointing to the same pseudo-string. Now if x.toString() is called, one approach is, allocate a buffer of size 11 and copy the strings “HI” and “Microsoft” one by one to the buffer. Later when Y.toString() and Z.toString() are called, we again allocate new buffers for each of them and copy the strings.

Hmmm. with such multiple allocations and copy operations, are we not back to the problem we were trying to solve? Yes, we are.

So how did we address this? Well, we decided not to have X, Y and Z point to actual pseudo-String. Instead they point to a proxy object, which keeps actual reference to pseudo-string. When X.toString() is called, conversion from pseudo-string to regular string happens (a new buffer of enough size is allocated and strings are copied one by one) and the proxy object is made point to regular string. Later when Y.toString() and z.toString() are called, we need not do the conversion again as they point to the proxy-object which already points to the regular string.

So X, Y and Z always point to the proxy-object. Proxy object may either contain a pseudo-string or a regular string, depending upon the time of conversion.

What if Pseudo-string is partially converted to regular string?

X = “Jscript” + “Team”;

Z = X + “Microsoft”;

X.toString();

In above snippet, X is a pseudo string and is used in formation of another pseudo string Z. Now toString() is called on X, so X has to be converted to regular string. Fine. I can do it. But wait a moment. X is used by another pseudo string Z. I can’t convert it just like that?

Well, as I said, all references to a pseudo-string are through the proxy-object. Hence Z also refers to the proxy object for X, not to the actual pseudo-string. So even after X is converted to the regular string, references to proxy object remain alive and things work perfectly.

And yes we had to test it J

‘Maintaining compatibility is priority no. 1’ – this is the mantra we all in the team swear by. At any cost we had to ensure that we don’t break real world when fix is out. Our test team has done an awesome job in ensuring it. They found couple of cool crashes, which were not directly in the new implementation, but because new implementation broke few assumptions made in the engine. Interesting part is that they were reported on the last day of our internal milestones; therefore we had to sit whole night gazing at our screens, fixing and testing them.

This is all about string append problem and I hope it was an interesting read. One more interesting performance improvement I have worked on in this release and would like to share with you all is ‘Arrays’, but we’ll leave that for another post so stay tuned.

- JP

Thank you - Smartsheet !

don.raman — Tue, 22 Jan 2008 11:47:00 GMT

We are constantly looking to engage with our customers on this blog and understand their pain-points, and in that spirit, it was really heartening to see the blog post by Mark Mader from Smartsheet. The JScript team is very appreciative of this kind of customer engagement and hope more customers frequent this blog and provide feedback to us. This helps us understand problems real-world customers face and provide solutions that benefit other customers.

Thank you, Mark !

Don Raman

Performance issues with "String Concatenation" in JScript.

shivaram.p — Wed, 17 Oct 2007 15:28:00 GMT

Hello Friends,
I am Jaiprakash and work as a Developer in the Jscript team. There is not much to tell about me except one fact - I can’t recall the last time when any of my teammates called me by my name, they just call me JPJ.

I know, you have seen pretty cool blogs in past from my team mates and I promise this one also not going to disappoint you. So coming to the point, I am going to talk about the famous ‘string append’ problem in Internet Explorer (or Jscript to be more accurate) and how are we going to fix it.

The Problem
let’s do a small experiment to get to it. Copy paste following code in an html file and run in Internet Explorer. Observe the time reported.

On my machine the time reported is 1922 ms (averaged out three times). As you see this code is doing nothing other than appending a 7 character string 20K times. And for such a trivial operation it is consuming almost 2 seconds. Phewww….
Impressed? Not yet. It still doesn’t appeal you? OK. Try increasing the no of appends and enjoy the show. Here is what I get on my box…

Appends	Time (ms)
10K	260
20K	1922
25K	6125
30K	11578

Well, I am sure you would be impressed by now. And I can feel your curiosity to know how Jscript makes such a trivial looking operation such a big one.

Not much, it uses a very trivial algorithm to append strings to get you to such a great show. Whenever it has to append two strings of size ‘m’ and ‘n’ each, it allocates a new buffer of size (m + n), copies the strings one by one, and returns this buffer back. Hmmm. This logic looks fine. What’s the deal then?

Let’s say you want to append 3 strings like following...

resultStr = “Jscript” + “String” + “Append”;

To give you the final result, Jscript first appends “Jscript” and “String”. It allocates a buffer of size 13, copies them one by one to the buffer and assigns the buffer to a temporary, let’s say temp1. Next it appends temp1 and “Append”, allocates a buffer of size 19, copies temp1 and “Append”, and assigns the result to resultStr. As you see, to generate final string for you it copied “Jscript” and “String” twice (temp1 and resultStr) and allocated one intermediate buffer. Imagine what happens when you append ‘n’ such strings. It will allocate n-1 buffers, copy each string (n-i) times where ‘i’ is the index at which the string appeared in the operation.

You might be thinking why Jscript was shipped with such an algorithm. Well, Jscript was meant to be used just as glue, not as full-fledge programming language as used in modern WebApps.

How it affects Real world Scenarios
Gone are the days when web apps used to be static text which was just retrieved from the server and displayed in your browser. Today’s world is AJAX, involves lot more interaction with server, and data received is not just the plain HTML. A modern WebApp fetches data from server; builds the page on your machine using Jscript and DOM APIs, and displays on your browser. And to build the page it has to generate HTML, which is nothing but text. And to generate HTML out of the pieces retrieved from server, it has to append them as strings. And as the applications are becoming smarter and smarter, they tend to minimize the interaction with server, and do as much processing as possible in your browser.

Let me give you some real world examples. You all must have used some or the other AJAX mail client like msn.com, outlook web access or yahoo mail beta. In your inbox, if you scroll down or up, they just update your mail list not the entire page. How it happens? It gets the information about mails from server, builds the table of your mails on the fly and displays in the browser.

Another good example would be Redfin which is actually AJAX based real estate portal. If you search a locality, it shows a map with location of all the results and below the map it shows details of each result. This table it constructs by appending several hundreds of strings.

These are just two. There are many more such. Basically what I want to convey is that string append is a pretty common and basic operation and probability is very high that large number of web apps get affected by this.

So we are fixing it!!!
We are trying an algorithm which avoids those intermediate buffer allocations and repeated copy operations. With this algorithm, I just ran the same test case and here are the numbers for you. Please note that the fix is still under progress so these numbers might change a bit here and there, however they should be enough to give you an idea of improvements.

Appends	Time (ms)
10K	23
20K	47
25K	62
30K	78

Shhhh. Numbers speak for themselvesJ.

JP, I Need this fix on my box, now!!!
I wish I could help you. You will have to wait till next release of Internet Explorer.

At last…
Please help us in helping you. If you have encountered other such script “hairballs”, do leave a note on any of the blogs published here. I want to publish more such blogs for youJ.

- JP

Automatic Update for JScript which is part Windows Script 5.7 release

don.raman — Sat, 15 Sep 2007 09:14:00 GMT

There has been some request and suggestion that when the JScript team feels that there are so many advantages of JScript update which went as part of Windows Script 5.7 release, why this is not being pushed as part of Windows Automatic Update. Well, we do agree that making the JScript DLL (which is part Windows Script 5.7 package) delivered as automatic update will indeed help us in many ways including:

Reaching a huge number of our customers. This being a push rather than a pull (where the user needs to go and download the package from Microsoft Download Center) will certainly help in having this installed on a large number of machines.
Web site owners/developers whose site has improved will indeed want to have their customer see the same improvements. Now the chances that their customer will also go to the download link and download the package is again bit low. However doing an automatic update will help them too.

When Microsoft started the concept of automatic update, many items like a bug fix/feature request also made part of this. This lead to some system being broken. So people were generally skeptical consuming the latest updates and be broken. Instead they chose to be vulnerable.

Microsoft as a company has tried its level best to erase this perception. As a result of this only high vulnerable bug fix (security bugs) and similar items are only passed as part of auto-update. This is to make sure that we push things which are extremely of high importance from security/vulnerability point of view. So it's very difficult to push in general bug fixes through auto-update.

However all said the JScript team is looking at this as a priority and we are going to make a case for this. Stay tuned for further updates.

Thanks,

Don Raman

Regular Expression optimization done in Jscript 5.7 release

don.raman — Thu, 06 Sep 2007 01:38:00 GMT

I modified my last blog many times. I was really amazed at the kind of response I got on this blog. Thanks for taking time and putting all the comments. Today I am going to talk at length the "Regular Expression" optimization we did in JScript that shipped with Windows Script 5.7 release. I could have changed my last blog but since I have already changed it so many times, I think it's just better to write a new one.

Web Developers who are using JSON protocol to describe their objects should read this blog as optimizations has been done in this area.If you are looking for other fixes that has gone in this release please get them from here. The improvements are quite evident for web sites which are using JSON protocol to define their objects. We got to know about this performance bug from our Windows Live team when they complained about poor performance of their web site while using JSON protocol. We were close to 30 times slower than the competition.

Now, let's take a moment to define what exactly was causing the problem. As part of using JSON protocol usage on Windows Live site, the code used to do pattern matching on a regular expression and further do some kind of replacement of matched string with a fixed specified string. The CPU time spend in doing this pattern matching and replace was very high which lead to the performance of site being bad.

Let’s take the example of the specified regular expression : /(["'])(\\.|((?!\1|\\).))*\1/g

While matching a pattern for this expressions, before going into the loop, JScript engine compares if source string right now is same as the source string that was present before entering the same loop last time. If source strings are same it doesn't enter the loop .Assumption being none of the characters in the source string were matched in the last iteration and there is no point in taking this loop again (because if this loop is taken again then it means engine is in infinite loop). Otherwise keep checking back all the loops down in the stack until either the above mentioned condition is true (both source strings are same) or it reaches bottom of the stack. If it reached bottom of the stack then this loop can be entered as it means that either this is the first time loop is being taken or loop consumed at least one character last time. Seems pretty perfect logic.

So what's the flaw with the above logic? What if the engine is going to take same loop but it matched one or more characters in the last branch. In this case above mentioned logic will still keep comparing all the loops till it reaches end of the stack and then it decides to take the loop. This is not correct. If few characters were consumed in the last loop then instead going till end of the stack, it must decide to take a loop as soon as it finds that last time part of the sources string was matched by this loop.

The fix actually addresses this bug. And as a result from being 30 times slower than the competition, we are now at par with competition. Now that's a good enough reason to start using the new JScript if you are using JSON protocol.

Thanks,

Don Raman.

Windows Script 5.7 released for Windows 2000, Windows XP and Windows 2003 Server

don.raman — Sun, 12 Aug 2007 08:31:00 GMT

I have little announcement to make today. Windows Script 5.7 which ships with different flavors of Windows® Vista is now available for Windows® 2000/XP as well as Windows® 2003 Server.

This download will install Microsoft® Windows® Script containing Visual Basic® Script Edition (VBScript.) Version 5.7, JScript® Version 5.7, Windows Script Components, Windows Script Host 5.7, and Windows Script Runtime Version 5.7.

Why should you care about this update ? If you ever encountered performance issues running AJAX applications (e.g. Gmail), you should absolutely consider installing this update. This update includes an updated Garbage Collector that used to previously make AJAX appliications run pretty poorly. This update is available on Vista and we are now providing this to all supported OS versions (XP, Win2K, Win2K Server). You will see noticeably better performance on your favorite AJAX applications and with more and more AJAX applications coming on line, you will be very happy you did this.

Below is the download link for the updates.

Download Windows Script 5.7 for Windows 2000

Download Windows Script 5.7 for Windows XP

Download Windows Script 5.7 for Windows 2003 Server

Also lot of people might be wondering what all changes has gone inside this release. A quick look at release note will give you all the detail. The release notes can be downloaded from here.

Happy downloading and enjoy all the benefits of Windows Script 5.7 on other OS too!!

Thanks,

Don Raman

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

don.raman — Wed, 24 Jan 2007 17:23:00 GMT

This is the first ever blog written by me in my entire life time. Let me take some time to introduce myself. I am Don Raman and work as a Test Lead in Microsoft India Development Center at Hyderabad. A part of my responsibility is to own the testing of JScript native language. I joined Microsoft six months back and I am pretty excited about working in such a great company. I am going to give some pointers/links to some good paper written by Microsoft employees which will help a JScript programmer write more efficient code.

Any programming language gives flexibility to the programmer to write the logic (code) using different language constructs. The same thing can be achieved in a different way. A programmer may think why writing code in a certain way will make things faster. But the way dynamic languages are architected it is very much possible that certain constructs or tricks can make your program run faster. Below are links which will definitely make you a more efficient JScript programmer.

http://blogs.msdn.com/ie/archive/2006/08/28/728654.aspx

http://blogs.msdn.com/ie/archive/2006/11/16/ie-javascript-performance-recommendations-part-2-javascript-code-inefficiencies.aspx

http://blogs.msdn.com/ie/archive/2007/01/04/ie-jscript-performance-recommendations-part-3-javascript-code-inefficiencies.aspx

The above articles are extremely good to understand some of the things going behind the code. It also has got some excellent post from the web community.

Thanks a lot for reading this post and I hope you have got benefited out of it.