performance of OO dispatch in inner loops
David.Teller at univ-orleans.fr
Fri Mar 21 13:31:14 PDT 2008
On Fri, 2008-03-21 at 12:42 -0700, Brendan Eich wrote:
> Again, I'm not writing checks I can't yet cash (but we are investing,
> making bets in code under development). On the other hand, IMHO you
> are pessimizing for the two-decade-old trailing edge. It's easy to go
> from "want speed" to "require static types" and bypass the "optimize
> dynamic types enough not to need more speed" state, but taking this
> shortcut risks leaving lots of developers and content behind. It's a
> huge rewrite tax at the limit, unpayable on the web.
I may be wrong but I have the feeling that the works you quote use
type-feedback and that type-feedback only optimizes [single] method
dispatch. ES4 has multi-methods, which are harder to optimize, plus
there are plenty of other checks that may be optimized away which are
related to typing but not to method dispatch, say pattern-matching,
"wrap", etc. In addition, iirc, type-feedback only works after the first
execution of code, so it is not necessarily useful when objects are
re-created at each execution of the body of a loop, etc.
Now, of course, I might be wrong. I'm not really a specialist in OOP
> What's more, if the static type system is weak, this course may just
> amount to requiring programmers to overspecify their code for the
> sake of VM implementors, without gaining much in the way of safety
> properties or other programming in the large benefits. Such
> overspecification can turn code into "hardware" that is hard to
> evolve quickly, mash up, merge and diverge, reuse at Web scale, etc.
I concur with that. In order to maintain readability, most optimizations
should happen behind-the-scene i.e. by using either type inference (or
something more complicated but of the same kind) or type-feedback.
Security of Distributed Systems
Angry researcher: French Universities need reforms, but the LRU act
More information about the Es4-discuss