[PHP-DEV] Re: [APC-DEV] [RFC] APC/PHP Lazy Loading
"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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [APC-DEV] [RFC] APC/PHP Lazy Loading
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [APC-DEV] [RFC] APC/PHP Lazy Loading
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
[PHP-DEV] Re: [APC-DEV] [RFC] APC/PHP Lazy Loading
Rasmus Lerdorf wrote: Gopal V wrote: shire wrote: http://tekrat.com/downloads/bits/apc_lazy_php53.patch You should be able to apply the above patch to the latest PHP_5_3 branch, and recompile the latest APC CVS against it. Two ini settings enable/display lazy loading: apc.lazy_functions=On/Off apc.lazy_classes=On/OFf Awesome! Yup, I am all for the lazy loading patch as well. I don't think people really realize how much code they load that is never run. Especially all the folks with massive front controllers. Thanks, I would be interested in hearing how successful it is on different setups just to validate it. I'll start making some more cleanups to the patches and more optimizations in the next month or two so hopefully we'll see some additional improvements in the code and performance. Alternative implementations would include replacing the function entries with an internal function that would load the opcodes when called, however I found this implementation to be problematic, still requires changes to PHP, and would also require inserting entries into the function/class tables which itself ends up being an expensive task for extremely large codebases. I still haven't given up on the executor hooks. But can't argue with code that works (yes, it works for most of my tests). By executor hooks do you mean actually the executor hooks in Zend, or replacing a stub in the function table like I described? I like the idea of stubbing out function table entries, but I think this makes it difficult to avoid the costs of updating the function table, I'm hoping that I can make some optimizations that cut this down so I guess we'll see in a while if I'm able to do that as it might shed some light on how much we can gain by going one way or the other etc. If you're thinking of something else (I know we discussed this before, but maybe I misunderstood), I'd like to hear the details. ;-) I should finish up the RO patches in place so that we can catch stuff being overwritten in shm without locks - reflection, xdebug and suhosin looks like potential culprits here. I thought this was awesome when I read your blog post, should be great! I wouldn't worry about xdebug at all. We should probably just turn off the opcode cache part when xdebug is active if it is a problem. 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. -shire -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [APC-DEV] [RFC] APC/PHP Lazy Loading
Gopal V wrote: > shire wrote: > >> http://tekrat.com/downloads/bits/apc_lazy_php53.patch >> >> You should be able to apply the above patch to the latest PHP_5_3 >> branch, and recompile the latest APC CVS against it. Two ini settings >> enable/display lazy loading: >> >> apc.lazy_functions=On/Off >> apc.lazy_classes=On/OFf > > Awesome! Yup, I am all for the lazy loading patch as well. I don't think people really realize how much code they load that is never run. Especially all the folks with massive front controllers. >> Alternative implementations would include replacing the function >> entries with an internal function that would load the opcodes when >> called, however I found this implementation to be problematic, still >> requires changes to PHP, and would also require inserting entries into >> the function/class tables which itself ends up being an expensive task >> for extremely large codebases. > > I still haven't given up on the executor hooks. But can't argue with > code that works (yes, it works for most of my tests). > > I should finish up the RO patches in place so that we can catch stuff > being overwritten in shm without locks - reflection, xdebug and suhosin > looks like potential culprits here. I wouldn't worry about xdebug at all. We should probably just turn off the opcode cache part when xdebug is active if it is a problem. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [APC-DEV] [RFC] APC/PHP Lazy Loading
shire wrote: http://tekrat.com/downloads/bits/apc_lazy_php53.patch You should be able to apply the above patch to the latest PHP_5_3 branch, and recompile the latest APC CVS against it. Two ini settings enable/display lazy loading: apc.lazy_functions=On/Off apc.lazy_classes=On/OFf Awesome! Alternative implementations would include replacing the function entries with an internal function that would load the opcodes when called, however I found this implementation to be problematic, still requires changes to PHP, and would also require inserting entries into the function/class tables which itself ends up being an expensive task for extremely large codebases. I still haven't given up on the executor hooks. But can't argue with code that works (yes, it works for most of my tests). I should finish up the RO patches in place so that we can catch stuff being overwritten in shm without locks - reflection, xdebug and suhosin looks like potential culprits here. Cheers, Gopal -- If I learn from my mistakes, pretty soon I'll know everything -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
