Normative: re-use IteratorResult objects in some iterator helpers

[michaelficarra]

This re-uses IteratorResult objects when it's possible to just pass the object through. There are currently 3 cases of this: take/drop/filter. See related PR for the iterator sequencing proposal, which also has this opportunity: tc39/proposal-iterator-sequencing#18

I actually don't like doing this for filter since filter observes the value, which would mean triggering a value getter both for filtering and by the eventual consumer.

[nicolo-ribaudo]

which would mean triggering a value getter both for filtering and by the eventual consumer.

Why do you consider this to only be bad for the .value getter and not for the .done getter, which would be double-triggered by all those methods?

[michaelficarra]

I think an expensive value getter is more likely than an expensive done getter.

[michaelficarra]

@nicolo-ribaudo Also, someone might be surprised that the resulting iterator yields values for which the predicate would return false. But we might just want to say 🤷‍♂️ getters admit weirdness.

edit: I've added a slide to the upcoming presentation covering interactions with getters.

[dminor]

@anba Do you have an opinion on this change?

[anba]

This change is possibly difficult to implement for JSC and SM, because both use self-hosted JS for their implementation and the proposed changes can't be easily implemented in JS. (yield* can't be used, because it performs one final IteratorValue when done, which is user-detectable.)

I guess this also applies to tc39/proposal-iterator-sequencing#18.

[michaelficarra]

because both use self-hosted JS for their implementation and the proposed changes can't be easily implemented in JS

Do you mean that they can't be easily implemented in JS at all, or do you mean using generators in JS? It seems manual iteration in JS should work fine.

yield* can't be used, because it performs one final IteratorValue when done, which is user-detectable

I'm open to also requiring the final IteratorValue to fully match a simpler generators/yield* implementation. One extra unnecessary property access at the end seems to be worth the savings of a whole extra object per item yielded.

[michaelficarra]

Ping @anba. It'd be great to have your feedback on the above points before plenary next week.

[anba]

Do you mean that they can't be easily implemented in JS at all, or do you mean using generators in JS? It seems manual iteration in JS should work fine.

When using generators. It's probably less of a problem when using normal functions instead of generators, but then it's necessary to duplicate the complete generator state machinery.

I'm open to also requiring the final IteratorValue to fully match a simpler generators/yield* implementation. One extra unnecessary property access at the end seems to be worth the savings of a whole extra object per item yielded.

I'm not sure about the performance impact when avoiding a single object allocation (per iteration). Local testing showed mixed results, but it's a bit difficult to estimate general performance changes, because I was only testing on SpiderMonkey. Getting results for a possible performance improvement is going to be difficult anyway, because:

1. SM doesn't fully support generators in its top tier compiler.
2. JSC doesn't pass through iterator objects in yield*.
3. V8 doesn't use generators at all for their Iterator Helpers implementation.

For example let's see what will change for Iterator.prototype.drop. The current SM implementation uses a normal for-of loop for the iteration:

for (var value of allowContentIterWithNext(iterator, nextMethod)) {
  if (remaining-- <= 0) {
    yield value;
  }
}

allowContentIterWithNext is an internal helper to be able to use for-of loops without duplicate property lookups. It's more or less similar to:

function allowContentIterWithNext(iterator, nextMethod) {
  return {
    [Symbol.iterator]() {
      return this;
    },
    next() {
      return nextMethod.call(iterator);
    },
    return() {
      // Elided for simplicity.
    },
  };
}

Rewriting the for-of loop using yield* will look like this in SM:

function iteratorNext() {
  while (remaining > 0) {
    var result = callContentFunction(nextMethod, iterator);
    if (!IsObject(result)) {
      ThrowTypeError(JSMSG_ITER_METHOD_RETURNED_PRIMITIVE, "next");
    }
    if (result.done) {
      return {done: true, value: undefined};
    }
    remaining -= 1;
  }
  return callContentFunction(nextMethod, iterator);
}

yield* allowContentIterWithNext(iterator, iteratorNext);

Changes:

1. An additional indirection through the new closure iteratorNext. That means, unless the compiler can fully inline iteratorNext, additional call overhead and overhead when accessing the iterator, nextMethod, and remaining variables.
2. Manual calls to next, including type checks and error reporting when remaining > 0.
3. And in my opinion a more complicated implementation.

[michaelficarra]

At plenary today, we have decided not to do this, setting precedent for other helpers on Iterator.prototype.