Le 13/07/2013 11:02, Brian Di Palma a écrit :
OK. So we have reached "Peak JavaScript" then.
That would be the reason why JS engines don't see 30x (or even 30%)
improvements from a year to another anymore. The JavaScript used on most
websites is fast now. The next boundary for performance is intensive
applications like games. Other than that, room for performance
improvements are to be found at different components like the DOM or
graphics
If people write JS code without triggering shape changes then the JIT
should be able to produce code that can match a JVM?
I would believe so. A bunch of talks from various JS engine implementors
explain that when your code has stable/predictable types, you pretty
much get the performance of... code with stable types. If a "+" is
always used with integers, it will be JIT-compiled as an integer
addition as it would in C (modulo some guards and overflow issues).
One of these talks http://www.youtube.com/watch?v=UJPdhx5zTaw (there are
plenty others)
If there was something that I could do as a developer that could help
the JIT I would do it.
Usually, the overlap between what JS devs consider good readable code
and what JITs need to optimize is very strong.
From my experience, anytime someone tries being smarter than writing
good code they end up using a fragile optimization (may work in some
engines, but not others, may become a performance issue as the targeted
engine changes over time. For reference, ~25% of a SpiderMonkey changes
each year
https://blog.mozilla.org/dmandelin/2011/11/29/js-development-newsletter-1123-1129/
)
Would ES6 classes not make the creation of shapes a lot easier? From
what I understand it takes time to figure out shapes/hidden-classes.
Well I'm marking this object as a class, does that help?
Implementors will answer better as I'm reaching the limits of my
knowledge, but when you read:
function C(){
this.a = 12;
this.b = "azerty";
}
C.prototype = {
...
}
var c = new C();
the shape is pretty clear and class syntax can hardly provide better
insight. Whether current engines already statically analyses functions
like C to get the same sort of info they would use from class syntax, I
don't know.
It would be interesting if engines provided feedback on when we
developers break the optimistic optimizations.
They have given a bunch of talks on the topic at various conferences
already. Search on Youtube if the link I gave above isn't enough ;-)
David
On Sat, Jul 13, 2013 at 9:43 AM, David Bruant <[email protected]> wrote:
Le 13/07/2013 10:21, Brian Di Palma a écrit :
I was just wondering
if the 'const' keyword would help give JS another small performance
boost.
Unlikely. Const can be almost statically inferred (no assignment to a given
variable). The "almost" refers to cases where eval happens. Worst case, if
there is no assignment, a variable can be optimistically optimized as const.
If the value is changed via eval, then de-optimize (but in practice, eval is
rare, so the optimistic optimization will be worth it)
As Andreas points out the major issue is that JS is highly dynamic,
this can be very useful sometimes but for most code it's not required.
Maybe if you mark everything as const or freeze/seal classes then
maybe JS engines will optimize for that code.
JS engines already optimistically optimize assuming code remains stable (for
objects, V8 has "hidden classes", SpiderMonkey has the equivalent "shape"
feature) and deoptimizes when the dynamic features are being used.
It might be one of the reason why maps are better at being maps than objects
(since objects seem to have been optimized for cases where they are stable)
David
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
