Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81549
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zeyos.com designates 109.70.220.166 as permitted sender)
Date: Mon, 02 Feb 2015 07:43:13 +0100
To: Dmitry Stogov <dmitry@zend.com>
Cc: PHP Internals <internals@lists.php.net>,
	Xinchen Hui <xinchen.h@zend.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset="UTF-8"
Message-ID: <20150202064317.A99835F84A@mx.zeyon.net>
Subject: Re: [PHP-DEV] Re: Improvements to array.c code base
From: ben.coutu@zeyos.com (Benjamin Coutu)

Hi Dmitry,=0A=0AI think Xinchen Hui has already implemented the range-funct=
ion suggestion. I very much appreciate that you are working on the for-each=
 optimization/consistency, this will improve things quite a bit. Focusing o=
n big improvements (thinking anything "hashtable") is absolutely the way to=
 go.=0A=0AThanks,=0A=0ABen=0A=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Original =3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=0AFrom: Dmitry Stogov <dmitry@zend.com>=0ATo: B=
enjamin Coutu <ben.coutu@zeyos.com>=0ADate: Mon, 02 Feb 2015 06:53:20 +0100=
=0ASubject: [PHP-DEV] Re: Improvements to array.c code base=0A=0AHi Benjami=
n,=0A=0AWe are in the state, when we mainly have to concentrate on big impr=
ovements=0Athat we have to deliver till mid of March.=0AI keep your ideas, =
but they are stuck at the end of my TODO list.=0A=0AThanks. Dmitry.=0A=0A=
=0AOn Tue, Jan 20, 2015 at 11:30 AM, Benjamin Coutu <ben.coutu@zeyos.com>=
=0Awrote:=0A=0A> Hi Dmitry,=0A>=0A> I was doing some code review of ext/sta=
ndard/array.c and have recognized=0A> some potential for a few performance =
improvements:=0A>=0A> =3D=3D=3D ARRAY_SLICE(..., preserve_keys=3Dfalse) =3D=
=3D=3D=0A>=0A> array_slice() can always construct a packed array if preserv=
e_keys is=0A> false, restricting it to inputs with packed flag does not mak=
e much sense.=0A> Removing the check for packed inputs on line 2376 would i=
mprove=0A> performance if used on non-packed inputs with the default=0A> pr=
eserve_keys=3Dfalse.=0A> Furthermore, ZEND_HASH_FOREACH_VAL should be used =
instead of=0A> ZEND_HASH_FOREACH_NUM_KEY_VAL on line 2379.=0A> It also thin=
k range() should use FAST_ZPP as it is a basic language=0A> feature (other =
languages even have extra operators for it, e.g. [0..10])=0A>=0A> =3D=3D=3D=
 RANGE(...) =3D=3D=3D=0A>=0A> range() always returns a numerically indexed =
array [0..count-1]. The=0A> resulting array therefore should be constructed=
 as a packed array=0A> (ZEND_HASH_FILL_PACKED+ZEND_HASH_FILL_ADD instead of=
=0A> zend_hash_next_index_insert_new).=0A>=0A> =3D=3D=3D ARRAY_FILL(start_k=
ey=3D0, ...)=0A>  =3D=3D=3D=0A>=0A> Just like with range(), array_fill() al=
ways returns a numerically indexed=0A> array [0..count-1] if start_key is 0=
. In this special but very common case=0A> the resulting array can be const=
ructed as a packed array=0A> (ZEND_HASH_FILL_PACKED+ZEND_HASH_FILL_ADD inst=
ead of=0A> zend_hash_next_index_insert_new).=0A> Another common case is for=
 start_key to be 1. One could refine the=0A> proposed packed-array branch t=
o just set the first bucket to undefined in=0A> this case.=0A>=0A> =3D=3D=
=3D COUNT(...) =3D=3D=3D=0A>=0A> count() is so ubiquitous! Giving it an opc=
ode and making it part of the VM=0A> seams reasonable.=0A>=0A> Please let m=
e know your thoughts.=0A>=0A> Cheers,=0A>=0A> Ben=0A>=0A> --=0A>=0A> Benjam=
in Coutu=0A> Zeyon Technologies Inc.=0A> http://www.zeyos.com=0A>=0A>