>> On Apr 25, 2014, at 7:07 AM, Andreas Rossberg <[email protected]> wrote: >> >>> On 25 April 2014 00:16, Allen Wirfs-Brock <[email protected]> wrote: >>> On Apr 24, 2014, at 2:33 PM, Mark S. Miller wrote: >>> >>> Excellent. Given that, how realistic is the performance concern for the >>> non-exceptional situation? Where is the overhead? >> >> the body of the for-of loop could directly or indirectly throw an exception >> or contain a break.The break can presumably be statically detected and >> cleanup handled by the break logic. But the loop still needs the equivalent >> of a finally around it, just in case an exception is thrown from the body. >> It's hander needs to invoke @@return on the generator. >> >> The point of debate is the cost of setting up that finally-equivalent, >> potentially for every for-of loop. The argument is that for some/most(??) >> current implementations there is significant runtime overhead to this setup. > > The broader argument is that this cost is imposed on the common use > case and has to be weighed against the utility it adds for a case that > is (1) rare, and (2) not well-motivated according to some participants > of the discussion (e.g., it's not necessarily a good idea to rely on > finally-blocks for scarce resource management in the first place, > since they provide only weak guarantees either way). > >> The contra argument is that there are technique that have zero to very low >> setup costs and that implementations may need to evolve to use them. > > To be sure, AFAICT none of these techniques have been demonstrated in > a JS-like language. Even in C++ land they have been a pipe dream for a > long time.
Try-catch is free in Java unless you throw. I wouldn't compare to C++ because current C++ implementations are limited by things like ABI standards. All JS-like languages are still in the baby stage of VM development; it's unfair to extrapolate future performance from current performance given how quickly things are changing. It's just a matter of common sense that JS implementations move to totally-free entry/exit into try-catch and a sensible cost model for when you throw, regardless of how this proposal goes. The fact that either of these things is a performance cliff is simply a bug and it will likely be fixed soon, given the pace of JS VM evolution. So I wouldn't let these performance concerns hold up figuring out the right semantics. -Filip _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
