Re: [RFC] Iterable
| From: | Aaron Piotrowski | Date: | Sun, 19 Jun 2016 16:35:50 +0000 |
| Subject: | Re: [RFC] Iterable | ||
| References: | 1 2 3 4 5 6 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-94126@lists.php.net to get a copy of this message | ||
> On Jun 18, 2016, at 6:11 PM, Dan Ackroyd <danack@basereality.com> wrote:
>
> Hi Aaron,
>
>> does anyone have any further feedback on this proposal?
>
> What is the performance impact of the RFC on the standard performance
> benchmarks?
>
> And can you comment on the performance of using iterable as a type for
> parameters/return types, compared to normal classes?
>
> cheers
> Dan
Hi Dan,
Great questions!
This RFC has litte to no impact to the standard performance benchmarks. These benchmarks do not have
functions with type declarations, so they are largely unaffected by an of the code changed by this
RFC.
The largest impact is to functions with scalar parameter or return type declarations. An extra
integer comparison is performed during the compilation step to check if the type declaration equals
IS_ITERABLE. [1] for parameter and [2] for return types. If a parameter is not a class name and has
a default argument, another integer compare is performed [3].
The patch also performs an additional integer compare to IS_ITERABLE when a type not directly
matching the type declaration is provided and the type declaration is a scalar type. This applies to
both parameter [4] and return type declarations [5].
User code using
iterable would only be slightly slower than using array or
Traversable, as a few extra integer comparisons are made and additional function call
is made to verify the type matches one of the two allowed types (see [4] and [5] again). However,
the flexibility provided by iterable is well worth this very small penalty. For
comparison, this overhead is far less than the callable pseudo-type as the value is not
examined, only the type.
In my tests against type declarations using other interfaces such as Iterator or
IteratorAggregate, using iterable was about equal in performance. [6]
Overall in my opinion, the performance impact of this RFC is negligible.
Dmitry, could you take a look at the patch and do some of your own performance checks?
Thanks!
Aaron Piotrowski
[1] https://github.com/php/php-src/pull/1941/files#diff-9760ee109b1c5922071fac1e19d117dfR332
[2] https://github.com/php/php-src/pull/1941/files#diff-9760ee109b1c5922071fac1e19d117dfR360
[3] https://github.com/php/php-src/pull/1941/files#diff-3a8139128d4026ce0cb0c86beba4e6b9R5082
[4] https://github.com/php/php-src/pull/1941/files#diff-a5fb5fd8c4f7311c6d0788763e665daaR857
[5] https://github.com/php/php-src/pull/1941/files#diff-a5fb5fd8c4f7311c6d0788763e665daaR1080
[6] https://gist.github.com/trowski/6f4b8b689228c7ba930fa658bb3c87f9