Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111754
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
In-Reply-To: <CA++kX6_Jd+mTeOdAe3UasAv5ZS-8xbUkjSNOj-LDgKryA4hqeA@mail.gmail.com>
Date: Mon, 31 Aug 2020 17:50:21 -0400
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <34212284-827A-41E1-B86B-F8B28214219C@zort.net>
References: <CA++kX6_Jd+mTeOdAe3UasAv5ZS-8xbUkjSNOj-LDgKryA4hqeA@mail.gmail.com>
To: =?utf-8?Q?Riikka_Kalliom=C3=A4ki?= <riikka.kalliomaki@riimu.net>
Subject: Re: [PHP-DEV] Request for couple memory optimized array improvements
From: jbafford@zort.net (John Bafford)

Hi Riikka,

> On Aug 31, 2020, at 14:13, Riikka Kalliom=C3=A4ki =
<riikka.kalliomaki@riimu.net> wrote:
>=20
> A common pattern that I've seen that could dearly use PHP internal
> optimization, if possible, would be:
>=20
> foreach (array_keys($array) as $key) {
> }

I have a draft RFC (https://wiki.php.net/rfc/foreach_void) and patch =
(https://github.com/jbafford/php-src/tree/foreachvoid against php 7.0, I =
think) that helps with this, by allowing the following syntax:

	foreach($iterable as $key =3D> void) { ... }

This would iterate over the keys of the iterable, and does not retrieve =
the values at all.

In theory, this should be a general performance win any time one needs =
to iterate over only the keys of an iterable, because it does not =
require the use of an O(n) iteration and building of the array that =
array_keys() would, plus it works on non-array types (such as generators =
or iterators). It also is more performant than foreach($iterable as $key =
=3D> $_) {}, because it omits the opcode that instructs the engine to =
retrieve the value. (Presumably, a future direction could include using =
this request to inform generators or iterators to only return keys, and =
not values, which could further improve performance, especially if value =
generation is expensive. But that is out of scope for this RFC.)

If this is something we'd like for PHP 8.1 and there are no major =
objections to the idea, then after 8.0 is released, I can move the RFC =
out of Draft and into Under Discussion, and presuming a vote passes, =
I'll update the patch as necessary to work against 8.0. But my time is =
limited and I'm not willing to put further time into the code unless an =
RFC vote passes.

Thoughts anyone?

-John