Newsgroups: php.apc.dev,php.internals
Path: news.php.net
Xref: news.php.net php.apc.dev:197 php.internals:43238
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <55.20.20645.2000DA94@pb1.pair.com>
To: apc-dev@lists.php.net,internals@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>
Date: Tue, 3 Mar 2009 13:01:38 +0300
Lines: 30
Subject: Re: [APC-DEV] [RFC] APC/PHP Lazy Loading
From: dmda@yandex.ru ("jvlad")

"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.
>
> -Rasmus

Rasmus,
Perhaps, you miss the point that people may want to measure performance (the 
speed)
using either xdebug or the other php profiling tools like dbg, zend's 
profiler, or apd.
If you turn the cache off, they'll certainly get misleading results pointing 
to wrong bottlenecks.
In other words, it's not apc should be adapted to xdebug. but xdebug should 
be adapted to
lazy loading. Therefore it's crusial to have the proposed feature 
well-documented somewhere (where btw?)
and  have certain mechanisms that would allow all kinds of debugger/profiles 
co-exist with
caches like apc.
-jv