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 <[email protected]> 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 > <[email protected]> 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 <[email protected]> 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 > >> [email protected] > >> https://mail.mozilla.org/listinfo/es-discuss > > > > > _______________________________________________ > 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
