+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
