On Tue, August 8, 2006 3:45 pm, Adam Zey wrote: > From a performance standpoint, if you're not using an opcode cache, > modularizing it will be faster, since PHP won't have to compile > functions that won't be used (PHP recompiles scripts every time they > are > run). However, if you're using an object cache like eAccelerator, APC, > or Zend Accelerator, then there is no performance benefit since the > opcodes are already compiled. > > This ignores disk accesses, but opcode caches will have everything > cached in memory anyhow, so if you're using an opcode cache that > wouldn't matter either. Ignoring disk accesses would be rather silly, if you actually time this for real... :-) As far as the Opcode cache goes, you have an even more interesting problem: How much can fit in the Opcode cache? How fast is the Opcode cache lookup, which is presumably based on filename? Does the Opcode filename lookup "scale" linearly? log(n)? O(1)? If you have only 10 functions, it's irrelevant -- If you're seeking an optimium for an Opcode cache with hundreds of thousands of functions potentially spread across thousands of files, it probably matters a great deal. And, even more then before, only testing on your hardware under realistic load would tell what was "best" because there are simply too many variables. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
