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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
