d at domenic.me (2015-02-21T00:38:51.672Z)
Agreed, I see the `.next()` issue similar to an `array.length` in a for loop where the code inside does not mutate the array anyhow. In that case there's no need to invoke the getter for the length at each iteration, so I guess one day we might have similar optimizations in place for generators. 'till that day though ... I rather use old school events for bigger IoT projects, those always played quite nice (and have been sharing the same event object for years now without a problem)
Agreed, I see the `.next()` issue similar to an `array.length` in a for loop where the code inside does not mutate the array anyhow. In that case there's no need to invoke the getter for the length at each iteration, so I guess one day we might have similar optimizations in place for generators. 'till that day though ... I rather use old school events for bigger IoT projects, those always played quite nice (and have been sharing the same event object for years now without a problem) just my 2 cents too On Mon, Feb 16, 2015 at 2:40 PM, Bradley Meck <bradley.meck at gmail.com> wrote: > I think it is important to not attempt to pre-optimize and create partial > solutions. I is fairly easy for the compiler to understand *when* > [Symbol.iterator] is invoked and optimize it at that point, same concept as > on the stack replacement. A better question in my book, is there any engine > author who is concerned about the difficulty of implementing such an > optimization. > > Having a shared object means much more escape tracking than if the object > was not shared. > > Just my 2 cents. > > On Mon, Feb 16, 2015 at 8:32 AM, Andreas Rossberg <rossberg at google.com> > wrote: > >> On 16 February 2015 at 15:21, Andrea Giammarchi < >> andrea.giammarchi at gmail.com> 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 <rossberg at google.com> >>> wrote: >>> >>>> On 15 February 2015 at 12:07, 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. =[ >>>>> >>>> >>>> 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 >>>>> <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 >>>>> >>>> >>>> >>> >> >> _______________________________________________ >> 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/2fe15404/attachment-0001.html>