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.



On Tue, Apr 28, 2015 at 4:28 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>
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" <allen at wirfs-brock.com>
> wrote:
>
>>
>> On Apr 27, 2015, at 3:29 PM, Tab Atkins Jr. wrote:
>>
>> On Mon, Apr 27, 2015 at 3:11 PM, John Lenz <concavelenz at gmail.com> 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
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150428/0e38dbc3/attachment.html>

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.