Uhm, early send, so I guess I didn't answer. Common pattern is to poll.next() a yield until its `done` property is `true` so that a value can be used.
This is I believe the common case that will create thousands of objects to be quickly trashed as garbage ... so I was wondering if those are all needed On Mon, Feb 16, 2015 at 2:38 PM, Andrea Giammarchi < [email protected]> wrote: > then frozen `{done: false}` without even the `value` property ... Would > this work or speed-up anything at all? > > On Mon, Feb 16, 2015 at 2:32 PM, Andreas Rossberg <[email protected]> > wrote: > >> On 16 February 2015 at 15:21, Andrea Giammarchi < >> [email protected]> wrote: >> >>> > Shared mutable result objects >>> >>> FWIW to me that could be even be a singleton frozen `{done: false, >>> value: null}` constant during iteration and a new object only once done. >>> >>> Would this work or speed-up anything at all? >>> >> >> Frozen value null? I don't understand. You'd get the actual values >> from... where? >> >> /Andreas >> >> >> On Mon, Feb 16, 2015 at 2:04 PM, Andreas Rossberg <[email protected]> >>> wrote: >>> >>>> 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
