Andreas Rossberg (2015-02-16T14:32:51.000Z)
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/5a575a91/attachment-0001.html>
d at domenic.me (2015-02-21T00:38:31.541Z)
Frozen value null? I don't understand. You'd get the actual values from...
where?