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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
