> On Feb 16, 2015, at 3:30 AM, Yusuke SUZUKI <utatane....@gmail.com> wrote: > > It's very timely to me. > > I'm now upgrading JavaScriptCore's iterator interface to allign to the latest > ES6 spec[1]. > However, since it allocates JS objects, it would cause performance > degradation.
JavaScriptCore has a pretty good object escape analysis and will not allocate short-lived objects in hot code (see here for the phase that eliminates allocations: http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/dfg/DFGObjectAllocationSinkingPhase.cpp <http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/dfg/DFGObjectAllocationSinkingPhase.cpp>). If you find that your changes cause object allocation even after the optimizing JIT kicks in, then please file a bug to that effect. > > Currently, I'm planning to add a loophole to improve perofrmance of iterating > builtin JS objects. > But if possible, I think it is preferable to change the spec to improve > performance of iteration for user provided iterators. I'm skeptical that spec changes will be necessary. -Filip > > [1]: https://bugs.webkit.org/show_bug.cgi?id=141351 > <https://bugs.webkit.org/show_bug.cgi?id=141351> > > Best regards, > Yusuke Suzuki > > On Sun, Feb 15, 2015 at 8:07 PM, Katelyn Gadd <k...@luminance.org > <mailto:k...@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. =[ > > 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 > <andrea.giammar...@gmail.com <mailto:andrea.giammar...@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 > > > > <http://webreflection.blogspot.co.uk/2013/06/on-harmony-javascript-generators.html> > > > > On Sun, Feb 15, 2015 at 10:06 AM, Katelyn Gadd <k...@luminance.org > > <mailto:k...@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@mozilla.org <mailto:es-discuss@mozilla.org> > >> https://mail.mozilla.org/listinfo/es-discuss > >> <https://mail.mozilla.org/listinfo/es-discuss> > > > > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org <mailto:es-discuss@mozilla.org> > https://mail.mozilla.org/listinfo/es-discuss > <https://mail.mozilla.org/listinfo/es-discuss> > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
