d at domenic.me (2015-02-21T00:39:06.304Z)
On 16 February 2015 at 15:41, Andrea Giammarchi <andrea.giammarchi at gmail.com> wrote: > 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 > Er, I don't think this is the common use case at all. You iterate over something to process values, otherwise there isn't much point in using iterators in the first place.
On 16 February 2015 at 15:41, Andrea Giammarchi <andrea.giammarchi at gmail.com > wrote: > 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 > Er, I don't think this is the common use case at all. You iterate over something to process values, otherwise there isn't much point in using iterators in the first place. /Andreas > On Mon, Feb 16, 2015 at 2:38 PM, Andrea Giammarchi < > andrea.giammarchi at gmail.com> 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 <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 >>>>>> >>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150216/e2fdee6a/attachment.html>