On 29 April 2015 at 02:21, John Lenz <concavelenz at gmail.com> 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 <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
>>>
>>>
>>>
>>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150429/5d394ab7/attachment.html>

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.