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
