Newsgroups: php.apc.dev,php.internals
Path: news.php.net
Xref: news.php.net php.apc.dev:195 php.internals:43189
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain tekrat.com from 208.43.138.18 cause and error)
Message-ID: <49A6EC70.9060406@tekrat.com>
Date: Thu, 26 Feb 2009 11:24:32 -0800
User-Agent: Postbox 1.0b7 (Macintosh/2009020805)
MIME-Version: 1.0
To: Rasmus Lerdorf <rasmus@lerdorf.com>
CC: Gopal V <gopalv@yahoo-inc.com>, 
 PHP Internals List <internals@lists.php.net>,
 apc-dev@lists.php.net
References: <49A097FE.10205@tekrat.com> <49A6A82C.9030504@yahoo-inc.com> <49A6C4D1.2060706@lerdorf.com> <49A6E6C8.90801@tekrat.com> <49A6E813.4030900@lerdorf.com>
In-Reply-To: <49A6E813.4030900@lerdorf.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [APC-DEV] [RFC] APC/PHP Lazy Loading
From: shire@tekrat.com (shire)

Rasmus Lerdorf wrote:
> shire wrote:
>> I agree for the general case, in our development environment though this
>> might cause some pains.  But we could always start there and see how it
>> goes.   I agree that Xdebug isn't really a use case we always need to
>> optimize for.
>
> Is it ever a case we need to optimize for?  If you are running xdebug,
> you aren't worried about execution speed.  You certainly aren't going to
> be running your PHP under xdebug in any sort of production environment.


I agree I don't see a case for ever using XDebug in a production environment with APC (unless you're providing some sort of developer service, and even then).  Obivously the user cache needs to function as you could be debugging something related.  In our development environment I'm just not sure how much additional time this will cost us in addition to xdebug.  I believe it takes 6 seconds (roughly there might be other crud going on there) for us to compile all the code into opcodes for execution, so tacking this on to xdebug might cause some headaches for developers.

But like I said, I think this case is pretty extraordinary, so for the sake of getting this great feture in if we need to disable this then I think I'm fine with figuring out some other solution to it should it actually be a problem at a later date. Even if I can disable this in APC then that might be enough to work around it.

-shire