On 29 April 2015 at 02:21, John Lenz <[email protected]> wrote: > I missed it, thanks. I know things will improve in time but I'm just > coming from a discussion with folks complaining about the performance of > generators and GC overhead in real code with Chrome and Firefox relative to > simple hand written loops. >
Note that there is a huge difference between optimising iterators (in particular, for-of), and optimising generators. I expect that VMs will start getting better on the former relatively soon, for iterators that are not generators. Making generators fast is a much more complicated problem. /Andreas On Tue, Apr 28, 2015 at 4:28 PM, Allen Wirfs-Brock <[email protected]> > wrote: > >> >> On Apr 28, 2015, at 4:21 PM, John Lenz wrote: >> >> You would hope that the engines might be able to create these objects on >> the stack but I don't think anyone does that yet and the result is a flood >> of eden objects. >> >> I would like to know I'm wrong about this. >> >> did you see >> https://esdiscuss.org/topic/performance-of-iterator-next-as-specified#content-15 >> >> >> A really good optimizing jit should be able to inline the 'next' call, >> recognize that the IterationResult object doesn't escape (it knows this for >> for-of loops) and not do an allocation at all. >> >> Allen >> >> >> >> On Apr 27, 2015 4:59 PM, "Allen Wirfs-Brock" <[email protected]> >> wrote: >> >>> >>> On Apr 27, 2015, at 3:29 PM, Tab Atkins Jr. wrote: >>> >>> On Mon, Apr 27, 2015 at 3:11 PM, John Lenz <[email protected]> >>> wrote: >>> >>> By which I mean the object that returns the current value and "done" >>> state? >>> >>> >>> IIRC, it's not supposed to. The built-in iterators will return fresh >>> objects each time, so there's no mutation hazard. Userland iterators >>> can of course violate this, but at their peril. >>> >>> >>> Well, that's not exactly what the ES2015 spec. says. The specification >>> of the Iterator interface ( >>> http://people.mozilla.org/~jorendorff/es6-draft.html#sec-iterator-interface >>> ) >>> does not require that the `next` method return a fresh object each time it >>> it called. So a userland iterator would not be violating anything by >>> reusing a result object. >>> >>> However, the specifications for all ES2015 built-in iterators require >>> that they return fresh objects. >>> >>> None of the built-in consumers of the Iterator interface (for-of, >>> Array.from, etc.) retain references to IteratorResult objects after testing >>> for `done` and accessing the `value`, so semantically they don't care >>> whether the ResultObject is reused. However, such reuse might preclude some >>> otherwise plausible engine level optimizations. >>> >>> Allen >>> >>> >>> >> > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
