Yusuke SUZUKI (2015-02-16T11:30:23.000Z)
It's very timely to me.

I'm now upgrading JavaScriptCore's iterator interface to allign to the
latest ES6 spec[1].
However, since it allocates JS objects, it would cause performance
degradation.

Currently, I'm planning to add a loophole to improve perofrmance of
iterating builtin JS objects.
But if possible, I think it is preferable to change the spec to improve
performance of iteration for user provided iterators.

[1]: https://bugs.webkit.org/show_bug.cgi?id=141351

Best regards,
Yusuke Suzuki

On Sun, Feb 15, 2015 at 8:07 PM, Katelyn Gadd <kg at luminance.org> wrote:

> I'm certainly in favor of VMs improving to handle that, and adding
> pressure for it is good. However, optimizing a TypedArray temporary
> arg to .set() is a much simpler problem than doing the escape analysis
> necessary to be certain a .next() result doesn't escape from a calling
> scope and isn't used after a later next() call. Applying pressure will
> be a good way to make sure VM authors do the work necessary for this
> to happen, but if iterators are unacceptably slow in shipping
> implementations for a year+ I think the odds are good that most
> shipping software will avoid using them, at which point VM authors
> will have no reason to optimize for primitives nobody uses. =[
>
> The fixed layout of the iterator object would allow the GC to allocate
> it cheaply and in the case of values (like ints) it wouldn't need to
> trace it either - so that helps a lot. But I don't know how realistic
> those optimizations are in practice.
>
> On 15 February 2015 at 02:36, Andrea Giammarchi
> <andrea.giammarchi at gmail.com> wrote:
> > +1 and I've raised same concerns 2 years ago [1]
> >
> > IIRC the outcome was that VM should be good enough to handle objects with
> > very short lifecycle, I'm still convinced (behind tests) that generators
> are
> > overkill for IoT devices (low clock and way lower RAM).
> >
> > Having always same object per iteration makes sense to me at least until
> > it's done so that could be just a struct-like `{done: false, value:
> null}`
> > object and GC will be happier than ever.
> >
> > Regards
> >
> >
> > [1]
> >
> http://webreflection.blogspot.co.uk/2013/06/on-harmony-javascript-generators.html
> >
> > On Sun, Feb 15, 2015 at 10:06 AM, Katelyn Gadd <kg at luminance.org> wrote:
> >>
> >> As specified, iterator .next() seems to be required to return a new
> >> object instance for each iteration.
> >>
> >> In my testing (and in my theory, as an absolute) this is a real
> >> performance defect in the spec and it will make iterators inferior to
> >> all other forms of sequence iteration, to the extent that they may end
> >> up being used very rarely, and developers will be biased away from Map
> >> and Set as a result.
> >>
> >> The issue here is that the new object requirement means that every
> >> iteration produces GC pressure. I think that past APIs with this
> >> problem (for example TypedArray.set) have proven that 'a sufficiently
> >> smart VM can optimize this' is not representative of real VMs or real
> >> use cases.
> >>
> >> In the specific case of .next(), the method returning a new object on
> >> every iteration does not produce any actual improvement to usability:
> >> There is no realistic use case that requires saving multiple next()
> >> results from the same sequence, as the sequence itself represents (at
> >> least in most cases) a container or generated value sequence that is
> >> fully reproducible on demand.
> >>
> >> I think allowing (or requiring) implementations to return the same
> >> object instance from every .next() call, or perhaps as a usability
> >> compromise, reusing a pair of objects on a round-robin basis (so that
> >> you can keep around the current and prior result) would be a very good
> >> decision here.
> >>
> >> In my testing Map and Set are outperformed by a trivial Object or
> >> Array based data structure in every case, *despite the fact* that
> >> using an Object as a Map requires the use of Object.keys() to be able
> >> to sequentially iterate elements. The cost of iterator.next() in v8
> >> and spidermonkey is currently extremely profound and profiling shows
> >> all the time is being spent in object creation and GC. (To be fair,
> >> self-hosting of iterations might improve on this some.)
> >>
> >> Oddly enough, I consider the ES iterator spec to be a big improvement
> >> over C#'s IEnumerable, in terms of usability/API. But this is an area
> >> where it is intrinsically worse performance-wise than IEnumerable and
> >> that's unfortunate.
> >>
> >> -kg
> >> _______________________________________________
> >> es-discuss mailing list
> >> es-discuss at mozilla.org
> >> https://mail.mozilla.org/listinfo/es-discuss
> >
> >
> _______________________________________________
> 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/20150216/92e00f4c/attachment.html>
d at domenic.me (2015-02-21T00:38:13.585Z)
It's very timely to me.

I'm now [upgrading JavaScriptCore's iterator interface to align to the
latest ES6 spec][1].
However, since it allocates JS objects, it would cause performance
degradation.

Currently, I'm planning to add a loophole to improve performance of
iterating builtin JS objects.
But if possible, I think it is preferable to change the spec to improve
performance of iteration for user provided iterators.

[1]: https://bugs.webkit.org/show_bug.cgi?id=141351
d at domenic.me (2015-02-21T00:37:58.546Z)
It's very timely to me.

I'm now upgrading JavaScriptCore's iterator interface to allign to the
latest ES6 spec[1].
However, since it allocates JS objects, it would cause performance
degradation.

Currently, I'm planning to add a loophole to improve perofrmance of
iterating builtin JS objects.
But if possible, I think it is preferable to change the spec to improve
performance of iteration for user provided iterators.

[1]: https://bugs.webkit.org/show_bug.cgi?id=141351