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
