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 <rossb...@google.com>
wrote:
> On 16 February 2015 at 15:21, Andrea Giammarchi <
> andrea.giammar...@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 <rossb...@google.com>
>> wrote:
>>
>>> On 15 February 2015 at 12:07, Katelyn Gadd <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. =[
>>>>
>>>
>>> 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.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
>>>> >
>>>> > On Sun, Feb 15, 2015 at 10:06 AM, Katelyn Gadd <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
>>>> >> 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
>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
