On Sep 13, 2011, at 1:02 AM, François REMY wrote: > Okay, maybe you don't have to seek throug a dictionnary anymore. But still, > the performance overhead is higher than you would want to. Because it's > possible to achieve no overhead, even a small overhead is an overhead to be > deleted. The fastest code is the code you don't have to execute.
You're right, small constant factors and terms matter asymptotically. More apples-to-oranges, but we have to weigh and decide: JS programmer productivity is not clearly helped by adding type annotations. We worked through a number of scenarios for ES4: * Typed code calling untyped code: dynamic barriers required to enforce invariants, this'll cost. * Untyped code calling typed code: spot-checks (remember "like") or barriers required, ditto. * The easy one, typed calling typed, but then you've probably harmed productivity by over-annotating. The gravity well is steep. AS3 went far down it and its users over-annotated. Different economics and tooling on the web, so maybe we'll be luckier -- or perhaps an attempt to sell optional type annotations will simply fail to close -- no widespread adoption. This all assumes we have a sound optional type system. We never had one for ES4. It's a research area. TC39 is not doing research, remember? > A compiler may be very dumb, if I say something is true, he know it's true. > On the other side, a compiler can be as smart as you want, there are things > he'll never be able to guess. Yes, but does JS need to run almost as fast as C? BTW, for well-behaved benchmarks using typed arrays, our tracing JIT does run about as fast as C. So really, you have to stipulate workload. For all workloads, must JS run almost as fast as C? No way! /be _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
