Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59415
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)
Mime-Version: 1.0 (1.0)
References: <CBA4CE74.11C02%luke@cywh.com> <2082600.13123.1333758215113.JavaMail.mobile-sync@iaje9>
 <7714055974799768995@unknownmsgid> <CAEZPtU5nquKWNogJ7hVW3Ov4wF_ZYB9ON61pKT+mAFtPWz_Aow@mail.gmail.com>
In-Reply-To: <CAEZPtU5nquKWNogJ7hVW3Ov4wF_ZYB9ON61pKT+mAFtPWz_Aow@mail.gmail.com>
Date: Sat, 7 Apr 2012 07:59:26 -0700
Message-ID: <3194191830858287831@unknownmsgid>
To: Pierre Joye <pierre.php@gmail.com>
Cc: =?ISO-8859-1?Q?Johannes_Schl=FCter?= <johannes@schlueters.de>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] Persistent zvals
From: luke@cywh.com (Luke Scott)

On Apr 7, 2012, at 5:22 AM, Pierre Joye <pierre.php@gmail.com> wrote:

> hi,
>
> 2012/4/7 Luke Scott <luke@cywh.com>:
>
>> 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.
>
> The expensive parts here are not the object creation on its own but to
> get the data they contain (external, calculation, etc.).

With heavy objects, yes. But when you have hundreds of objects? The
unseralization process in no more efficient than creating the objects
directly.

> That's why we have magic methods like __sleep and __wakeup. Making
> objects or values persistent across requests is not possible or very
> hard. It is way cleaner to create them on each request and save the
> expensive computation or data fetching time (see doctrine for example)
> instead of trying to figure out tricks to get rid of the references
> and all other ways to mess  up a zval between requests.

It depends. It's only cheaper when you have heavy objects.

How do other platforms with a persistent application instance handle this?

I don't believe references are really that big of an issue. You still
have scope and refcounts. The difference is now refcounts are ignored
and everything is thrown away at the end of the request vs refcounts
being observed and memory persisting past the request.

I think the bigger issues are how to persist the memory without
fragmentation. Stanislav talked about that (although those comments
didn't make it to the list - my fault for not hitting reply all).

> The serialization method can be optimized easily, igbinary for example
> can help to speed up this process.

Optimized, sure. But you can only go so far. You still have the cost
of recreating those objects. The only way to make it truly zero is by
not recreating them.

igbinary helps. But what about a large binary tree? The only way to
efficiently keep this in memory (currently) is to write a C/C++
extension that persists the memory as a resource. But this takes much
more time and effort than writing it in PHP.

> It is also important to keep in mind that PHP is not designed to have
> persitant user land values and won't be.
> There are very good tools to
> store these data, like memcached, couchbase, redis and co for the
> distributed ones, apc and other for local caches (even like mysqlnd_cc
> for caching mysql results :).

And these are great solutions to a different set of problems. But they
aren't the token solution to every problem.

With a lot of large frameworks you spend more time initializing the
framework than the request itself (besides querying external resources
like MySQL).

I think the most frustrating thing for me is knowing this isn't an
issue with web applications written in Java, which has an always on
application instance that handles requests. I've always viewed java as
bloated and slow... But with recent developments of Java being jit
compiled to native code, these issues are starting to go away.

I have invested 10 years into PHP. Id rather stick with what I know.
But it scares me that many enterprises in our sector chose Java over
PHP.

Luke

>
> Cheers,
> --
> Pierre
>
> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org