Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94145
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 65.55.169.127 as permitted sender)
To: Aaron Piotrowski <aaron@trowski.com>, Dan Ackroyd <danack@basereality.com>
CC: "internals@lists.php.net" <internals@lists.php.net>
Thread-Topic: [PHP-DEV] [RFC] Iterable
Thread-Index: AQHRyXcEYsKFn/7XVUmGbphMRFgZVJ/v2nYAgAEj4gCAAPQQNA==
Date: Mon, 20 Jun 2016 07:12:35 +0000
Message-ID: <BY2PR0201MB1784173632E772A501A53F0ABF2A0@BY2PR0201MB1784.namprd02.prod.outlook.com>
References: <8284FE1F-70EE-4DB6-A945-0C57A4C99DCC@trowski.com>
 <16ef864f-8378-1af3-ddfb-21dc583a4b4a@gmx.de>
 <CAFMT4NrTDLhU912CQH55Y8z+M0s_qyP_FOxLKALwUcV0xB52Fw@mail.gmail.com>
 <d502f27c-869a-e46b-186d-9653f154bdf3@fleshgrinder.com>
 <35132CB5-6E11-477F-8AC6-4374A7434D43@trowski.com>
 <CA+kxMuRkzMqjCM+DWGb_vDPW-O1Btc5Gk=TfoQwk59cjNPUrGg@mail.gmail.com>,<549528A0-E6D0-4413-B8C3-CD3C37685E53@trowski.com>
In-Reply-To: <549528A0-E6D0-4413-B8C3-CD3C37685E53@trowski.com>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: zend.com does not designate
 permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative;
	boundary="_000_BY2PR0201MB1784173632E772A501A53F0ABF2A0BY2PR0201MB1784_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jun 2016 07:12:35.7579
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 32210298-c08b-4829-8097-6b12c025a892
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0201MB1782
Subject: Re: [PHP-DEV] [RFC] Iterable
From: dmitry@zend.com (Dmitry Stogov)

--_000_BY2PR0201MB1784173632E772A501A53F0ABF2A0BY2PR0201MB1784_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

From the first look, the patch shouldn't make any visible effect on perform=
ance.

According to the proposed new pseudo type - I don't have any strong opinion=
.


Thanks. Dmitry.

________________________________
From: Aaron Piotrowski <aaron@trowski.com>
Sent: Sunday, June 19, 2016 7:35:50 PM
To: Dan Ackroyd
Cc: internals@lists.php.net; Dmitry Stogov
Subject: Re: [PHP-DEV] [RFC] Iterable


> 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. The=
se benchmarks do not have functions with type declarations, so they are lar=
gely unaffected by an of the code changed by this RFC.

The largest impact is to functions with scalar parameter or return type dec=
larations. 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 def=
ault 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 d=
eclaration 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 addition=
al 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 `iterab=
le` 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, onl=
y the type.

In my tests against type declarations using other interfaces such as `Itera=
tor` or `IteratorAggregate`, using `iterable` was about equal in performanc=
e. [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 performa=
nce checks?

Thanks!

Aaron Piotrowski

[1] https://github.com/php/php-src/pull/1941/files#diff-9760ee109b1c5922071=
fac1e19d117dfR332
[2] https://github.com/php/php-src/pull/1941/files#diff-9760ee109b1c5922071=
fac1e19d117dfR360
[3] https://github.com/php/php-src/pull/1941/files#diff-3a8139128d4026ce0cb=
0c86beba4e6b9R5082
[4] https://github.com/php/php-src/pull/1941/files#diff-a5fb5fd8c4f7311c6d0=
788763e665daaR857
[5] https://github.com/php/php-src/pull/1941/files#diff-a5fb5fd8c4f7311c6d0=
788763e665daaR1080
[6] https://gist.github.com/trowski/6f4b8b689228c7ba930fa658bb3c87f9


--_000_BY2PR0201MB1784173632E772A501A53F0ABF2A0BY2PR0201MB1784_--