On 15 February 2015 at 12:07, 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. =[ > Engines are still ramping up on ES6 features, and most probably haven't been able to put much resources into optimisations yet (ES6 is large!). You can't compare it to old features that have been tuned for a decade and expect equal performance. This situation is unfortunate but unavoidable. Either way, it doesn't justify cutting corners in the semantics in a naive and premature attempt to optimise (which might even harm more highl-level optimisations on the long run). Shared mutable result objects would be a horrible API with footgun potential, especially when you start to build stream abstractions on top. FWIW, this has been discussed at length at some of the meetings. 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. > Not sure what you mean here. Unfortunately, result objects are still mutable and extensible, so anything can happen. /Andreas 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
