IDE support?

[François REMY]

Okay, maybe you don't have to seek throug a dictionnary anymore. But still, 
the performance overhead is higher than you would want to. Because it's 
possible to achieve no overhead, even a small overhead is an overhead to be 
deleted. The fastest code is the code you don't have to execute.

A compiler may be very dumb, if I say something is true, he know it's true. 
On the other side, a compiler can be as smart as you want, there are things 
he'll never be able to guess.

And even if the compiler is able to guess (and makes things faster using 
hidden classes and all other stuff modern VM implemented), it will take CPU 
time to guess things I already knew at the moment where I started writing my 
code. And each time my script will run, the browser will need to figure some 
stuff out. What a waste of energy, in a world where power efficiency is key.



-----Message d'origine----- 
From: Brendan Eich
Sent: Tuesday, September 13, 2011 9:33 AM
To: François REMY
Cc: John J Barton ; es-discuss at mozilla.org
Subject: Re: IDE support?

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