Performance improvements using iterator aggregates

[drupol]

This PR:

• Replaces IterableIterator with IterableIteratorAggregate (4 occurences)
• Changes the signature of a couple of operations.
• Update all the annotations where an Iterator is needed while now an iterable is enough.
• Use yield from - align everything
• Get rid of ClosureIterator and replace it with ClosureIteratorAggregate

Based on the benchmarks I did in loophp/iterators, it seems to be definitely, and it make sense.
IteratorAggregates are usually faster because the state of the Iterator is not built in userland but directly handled by PHP internaly.

$ ./vendor/bin/phpbench run --profile=local --group=local --report=aggregate --stop-on-error tests/benchmarks/IterableIteratorAggregateBench.php tests/benchmarks/IterableIteratorBench.php
PHPBench (1.2.3) running benchmarks...
with configuration file: /home/pol/dev/git/iterators/phpbench.json
with PHP version 8.1.1, xdebug ❌, opcache ✔

\benchmarks\loophp\iterators\IterableIteratorAggregateBench

    bench # IterableIteratorAggregate.......I0 - Mo1.963ms (±0.00%)
    bench # IterableIteratorAggregate.......R1 I7 - Mo0.937ms (±1.97%)
    bench # IterableIteratorAggregate.......R1 I25 - Mo0.927ms (±1.60%)

\benchmarks\loophp\iterators\IterableIteratorBench

    bench # IterableIterator................R1 I0 - Mo2.188ms (±0.00%)
    bench # IterableIterator................R1 I6 - Mo1.765ms (±1.80%)
    bench # IterableIterator................R4 I49 - Mo1.741ms (±2.25%)

Subjects: 2, Assertions: 0, Failures: 0, Errors: 0
+--------------------------------+---------+---------------------------+------+-----+----------+---------+--------+
| benchmark                      | subject | set                       | revs | its | mem_peak | mode    | rstdev |
+--------------------------------+---------+---------------------------+------+-----+----------+---------+--------+
| IterableIteratorAggregateBench | bench   | IterableIteratorAggregate | 10   | 1   | 3.695mb  | 1.963ms | ±0.00% |
| IterableIteratorAggregateBench | bench   | IterableIteratorAggregate | 10   | 10  | 3.695mb  | 0.937ms | ±1.97% |
| IterableIteratorAggregateBench | bench   | IterableIteratorAggregate | 10   | 50  | 3.695mb  | 0.927ms | ±1.60% |
| IterableIteratorBench          | bench   | IterableIterator          | 10   | 1   | 3.695mb  | 2.188ms | ±0.00% |
| IterableIteratorBench          | bench   | IterableIterator          | 10   | 10  | 3.695mb  | 1.765ms | ±1.80% |
| IterableIteratorBench          | bench   | IterableIterator          | 10   | 50  | 3.695mb  | 1.741ms | ±2.25% |
+--------------------------------+---------+---------------------------+------+-----+----------+---------+--------+

@AlexandruGG WDYT of this? Are you ok with this?

[AlexandruGG]

Looks good at a first glance, let me know when it's ready for review and I'll go through it more in-depth 👍

[drupol]

I think it's done.

This is something I should have done a long time ago.

[AlexandruGG]

is removing this intentional?

[drupol]

Yeah, I think we should even get rid of them everywhere. psalm doesn't handle them correctly anyway. I really wanted to avoid updating the baselines too much.

[AlexandruGG]

I just noticed some of these @pure annotations are being removed, but not everywhere. I think just in src/Collection.php?

How come this is needed?

[drupol]

Same comment as the previous one. We are not the only ones... https://github.com/marcosh/lamphpda/blob/master/adr/2022-01-25-pure-callable.md

[AlexandruGG]

Same comment as the previous one. We are not the only ones... https://github.com/marcosh/lamphpda/blob/master/adr/2022-01-25-pure-callable.md

I get this one, but in this project we didn't go that far to use pure-callable types 😬 .

I think the errors you saw in this project might be related to the iterators project not having things marked as @pure.

In any case it might be too much of a hassle to maintain this kind of stuff in PHP, in which case I think it's fine to remove them but we can do it for the whole codebase. You can do it in a separate PR though