Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59388
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain cywh.com from 209.85.220.170 cause and error)
References: <CBA4CE74.11C02%luke@cywh.com> <2082600.13123.1333758215113.JavaMail.mobile-sync@iaje9>
In-Reply-To: <2082600.13123.1333758215113.JavaMail.mobile-sync@iaje9>
Mime-Version: 1.0 (1.0)
Date: Fri, 6 Apr 2012 20:33:17 -0700
Message-ID: <7714055974799768995@unknownmsgid>
To: =?ISO-8859-1?Q?Johannes_Schl=FCter?= <johannes@schlueters.de>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Persistent zvals
From: luke@cywh.com (Luke Scott)

On Apr 6, 2012, at 5:23 PM, "Johannes Schl=FCter" <johannes@schlueters.de> =
wrote:

> Hi,
>
> On Fri, 2012-04-06 at 16:46 -0700, Luke Scott wrote:
>>
>>
>> From what I've gathered thus far, it is impossible to do without
>> copying the non-persistent memory into persistent memory, and then
>> back again. I'm assuming this is because all the memory associated
>> with PHP variables use emalloc, which places it onto a stack that is
>> disposed of at the end of the request.
>>
>> So there seems to only be two ways to do this:
>>
>> 1 - Copy non-persistent memory into persistent memory (and back) using
>> a deep copy. Probably not very efficient. May not be much better than
>> serialization.
>
> Yes, see apc_store() and friends to see all the small parts needed to
> copy it as properly as possible. While this still won't work for all
> cases (resources, internal classes, ..) but well, this might be what
> you're looking for in a ready state ;-)

Apc serializes the data. Unless the data is a cache or session
information there is almost no difference between unseralizing a bunch
of objects verses and initializing the objects in code.

It would be ideal of you could initialize a bunch of objects once and
carry them over to the next request. No serialization, no copying. A
lot of framework objects would benefit from this.

>
>> 2 - Modify the Zend engine to flag objects/zvals as persistent so they
>> aren=B9t thrown away until the process ends.
>
> Which is a major undertaking, taking copy-on-write and friends into
> account. As in a case like
>
>    mark_persistent($persistent);
>    $persistent['some key'] =3D function_returning_lots_of_data();
>
> would suddenly require to create a copy of all the data. Such things can
> quickly cost more than recreating the structures more frequently ...

When having to copy data, yes thing yet messy very quickly. But if
there were a persistent flag on the zval the new zval would have the
persistent flag. The old one would be discarded when it's reference
count reached zero.

Right now everything is thrown out at the end of the request because
it's created with emalloc, regardless of the recount. With a
persistent flag (1 or 0) and a recount of 1 or greater it wouldn't be
until the end of the process. Easier said than done - for sure.

>
> johannes
>
>