Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:46743
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 63.205.162.117 as permitted sender)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 14 Jan 2010 19:25:30 -0800
Message-ID: <698DE66518E7CA45812BD18E807866CE03B8009B@us-ex1.zend.net>
In-Reply-To: <4B4E8D15.60508@wikimedia.org>
Thread-Topic: [PHP-DEV] About optimization
Thread-Index: AcqUyGazLmEbA1c4TQmnIwASM8OSAwAybm+A
References: <4B4DABED.4060202@easyflirt.com> <hikb2l$q54$1@ger.gmane.org> 	<4B4DBF40.5040801@easyflirt.com> <4B4DCFDA.6090206@dmi.me.uk> <e382ba1001130725k5095fcdcqb305d7b5043b70e8@mail.gmail.com> <4B4DF01A.1080103@wikimedia.org> <4B4DFBDE.1020906@lerdorf.com> <4B4E5943.3000706@wikimedia.org> <4B4E5D5B.9020805@zend.com> <4B4E6BE5.1070404@wikimedia.org> <4B4E79A6.2010904@zend.com> <4B4E8D15.60508@wikimedia.org>
To: "Tim Starling" <tstarling@wikimedia.org>,
	"Stas Malyshev" <stas@zend.com>
Cc: <internals@lists.php.net>
Subject: RE: [PHP-DEV] About optimization
From: andi@zend.com ("Andi Gutmans")

> -----Original Message-----
> From: Tim Starling [mailto:tstarling@wikimedia.org]
> Sent: Wednesday, January 13, 2010 7:19 PM
> To: Stas Malyshev
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] About optimization
>=20
> Stanislav Malyshev wrote:
> >
> > opcodes can be cached (bytecode caches do it) but op_array can't
> > really be cached between requests because it contains dynamic
> > structures. Unlike Java, PHP does full cleanup after each request,
> > which means no preserving dynamic data.
>=20
> APC deep-copies the whole zend_op_array, see apc_copy_op_array() in
> apc_compile.c. It does it using an impressive pile of hacks which
break with
> every major release and in some minor releases too. Every time the
compiler
> allocates memory, there has to be a matching shared memory allocation
in
> APC.
>=20
> But maybe you missed my point. I'm talking about a cache which is
cheap to
> construct and cleared at the end of each request. It would optimise
tight loops
> of calls to user-defined functions. The dynamic data, like static
variable
> hashtables, would be in it. The compact pointerless structure could be
stored
> between requests, and would not contain dynamic data.
>=20
> Basically a structure like the current zend_op_array would be created
on
> demand by the executor instead of in advance by the compiler.
>=20
> >
> > I'm not sure how using pointers in op_array in such manner would
help
> > though - you'd still need to store things like function names, for
> > example, and since you need to store it somewhere, you'd also have
> > some pointer to this place.
>=20
> You can do it with a length field and a char[1] at the end of the
structure. When
> you allocate memory for the structure, you add some on for the string.
Then
> you copy the string into the char[1], overflowing it.
>=20
> If you need several strings, then you can have several byte offsets,
which are
> added to the start of the char[1] to find the location of the string
in question.
> You can make the offset fields small, say 16 bits.
>=20
> But it's mostly zend_op I'm interested in rather than zend_op_array.
> Currently if a zend_op has a string literal argument, you'd make a
zval for it
> and copy it into op1.u.constant. But the zval allocation could be
avoided. The
> handler could cast the zend_op to a zend_op_with_a_string, which would
have
> a length field and an overflowed char[1] at the end for the string
argument.=20

I tried the char[1] trick in the past. I can't quite remember why I
passed on it but I think because it now changed the sizes from zval from
being fixed and therefore couldn't efficiently cache zval allocations in
the memory manager (and of course this does not work with zend_opline
like structures where we have more than one zend_op(zval) in the
structure.

Andi