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
