IDE support?

François REMY fremycompany_pub at
Mon Sep 12 23:58:41 PDT 2011

When you see Microsoft and Apple both spending a lot of time just to get 
"scrolling a list" smooth and at 60fps, I assume there will always be a need 
for more performance. That all applications will not require that, I can 
understand it. But, again, let the developper free to decide if he need 
types or not.

Let me explain something (maybe you all know it, but you just didn't notice 
how important it is).

    function(x) {;

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) {;

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 :


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.


-----Message d'origine----- 
From: John J Barton
Sent: Tuesday, September 13, 2011 2:05 AM
To: François REMY
Cc: es-discuss at
Subject: Re: IDE support?

> From: "François REMY" <fremycompany_pub at>
> To: <es-discuss at>
> Date: Mon, 12 Sep 2011 22:31:17 +0200
> Subject: Re: IDE support?
> Types are not only "desirable" to borrow concepts from current IDEs. We 
> know from DotNET that a language running in a VM can be pretty fast, close 
> to a native language. But it has to be simple for the computer. JavaScript 
> is simple for the developer, but sometimes its flexibility makes it 
> impossible to "optimize" code properly. And it makes JavaScript slower.
> Or, to be exact, it doesn't allow to make 95% of our code faster because 
> it would break the other 5%. The more a compiler understand what you're 
> doing, the more it will be confident that optimizing is safe. Types may be 
> part of the data a compiler may use. It doesn't need to be the only one, 
> but it can be a very important one.

Ah, but let's be exact then: what proportion of most Web applications
will benefit from type-based performance improvements?

The reason I ask is that the diagrams that Wes posted show two things.
One is obvious: the dramatic improvement in JS. Yay! Congrats to all

The other is less obvious: further improvements in JS performance are
less and less important.  Not "unimportant" and not "insignficant".
Just less important because the total performance depends on many
factors of which JS -- for most pages most of the time -- may no
longer be the critical factor.  And even when JS is important,
type-based improvements will only be a small factor really. In the big
picture, such a fundamental change may not be very valuable.

Of course I am guessing, and having real performance analysis numbers
would be excellent information.


More information about the es-discuss mailing list