Closed marc-mabe closed 5 years ago
Even further optimized:
+----------------+-------------------+--------------+--------------------+-----------------------+
| benchmark | subject | tag:4.x:mean | tag:generator:mean | tag:newInterator:mean |
+----------------+-------------------+--------------+--------------------+-----------------------+
| EnumSet66Bench | benchIterateFull | 83.580μs | 35.053μs | 100.906μs |
| EnumSet66Bench | benchIterateEmpty | 0.510μs | 0.571μs | 18.026μs |
| EnumSet32Bench | benchIterateFull | 33.086μs | 15.915μs | 41.721μs |
| EnumSet32Bench | benchIterateEmpty | 0.401μs | 0.825μs | 7.150μs |
+----------------+-------------------+--------------+--------------------+-----------------------+
Love it!
Sidenote: Generator::send/throw is mostly used for coroutines in PHP. I didn't encounter any other use case so far, expect to create nice bugs to make people crazy.
Using a
Generator
makes it even faster iterating through elements of anEnumSet
as a directIterator
implementation. Instantiating theGenerator
seems to take more time (and memory) as seen in iterating an emptyEnumSet
but I think this is reasonable.But using a generator has some small downsides but in my opinion all of them are negligible:
Generator::key()
andGenerator::current()
returnNULL
on an invalid iterator positionGenerator::rewind()
throw an exception as it's not supported after starting.Generator::getReturn()
- I don't return anythingGenerator::send
- I don't use any return value onyield
Generator::throw
- I don't expect any exceptions to be thrownGenerator
. Instead I only defineIterator
. I would add that as implementation detail on documentation to not expect aGenerator
returned to be not limited in any feature releases because of that.ping @prolic