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) {
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.
François
-----Message d'origine-----
From: John J Barton
Sent: Tuesday, September 13, 2011 2:05 AM
To: François REMY
Cc: [email protected]
Subject: Re: IDE support?
From: "François REMY" <[email protected]>
To: <[email protected]>
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
involved!
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.
jjb
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
