IDE support?

[Brendan Eich]

On Sep 12, 2011, at 11:58 PM, François REMY wrote:

> Let me explain something (maybe you all know it, but you just didn't notice how important it is).
> 
>   function(x) {
>       x.data++;
>   }
> 
> This code is slow by nature. Because you don't know what kind of data "x" will be, you need to call "ToObject" before using it. Then you need to seek throug a Dictionnary(Of String -> PropertyDescriptor) to get the revelant property. When you've found your property in the dictionnary, you can increment its value. Even with a BTREE and optimized objects, you'll end up by performing far more operations than just incrementing an INTEGER variable as in C++.
> 
> However, if you had written
> 
>   function(x : MyType) {
>       x.data++;
>   }
> 
> the compiler would know that the "data" property of a "MyType" instance is stored 4 bytes after where the instance pointer is located in memory. The compiler knows it's an integer property and it can issue very few operation statements in native code :
> 
>   LOAD *x; LOAD 4; ADD; INCREMENT-REF;
> 
> The difference between those two codes are minimal for the developer, but they can improve the speed a lot. Optimizing RegExps, Dates, and even number operations, all of that is fine to get a better score in the SunSpider test. But it will never make ECMAScript a "fast" language. Just a less slow one.

You are simply way out of date on JS optimizing VMs, which (based on work done with Self and Smalltalk) all now use "hidden classes" aka shapes and polymorphic inline caching to optimize to exactly the pseudo-assembly you show, prefixed by a short (cheap if mispredicted) branch.

What's more, SpiderMonkey bleeding edge does semi-static type inference, which can eliminate the guard branch.

Please don't keep repeating out of date information about having to "seek through a dictionary". It simply isn't true.

/be