Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59635
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4F83E02F.8030902@php.net>
References: <CBA4CE74.11C02%luke@cywh.com>
	<11343239.3338.1333757773882.JavaMail.mobile-sync@iakr3>
	<2087324446797252296@unknownmsgid>
	<4F82F6E9.7050900@php.net>
	<1366176333732756257@unknownmsgid>
	<4F83E02F.8030902@php.net>
Date: Tue, 10 Apr 2012 11:51:34 +0200
Message-ID: <CAEZPtU4kmHEcq05d9DVVwN4sY0Mx_=yYqH-8cb=ox+H8jS01tQ@mail.gmail.com>
To: flavius@php.net
Cc: Luke Scott <luke@cywh.com>, "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] Persistent zvals
From: pierre.php@gmail.com (Pierre Joye)

hi,

On Tue, Apr 10, 2012 at 9:24 AM, Flavius Aspra <flavius.as@gmail.com> wrote:

> I also subscribe to the opinion of object persistency not being worth it. In
> an application server, you could probably achieve more by keeping the entire
> phar in RAM.
>
> Currently, you can also simulate that by putting the phar on a ramdisk or
> similar.


That's unrelated. Also having the phar in RAM is also not that useful
as it is exactly what an opcode cache does, while keeping the parsed
("compiled") code in memory cache.

Pre instantiated instances mean than a given app won't have to do all
the include foo;+ new foo();  As it is somehow expensive, relative the
the footprint of a given framework core.

Cheers,
--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org