Re: Re: Performance Consideration of 1 class

Hi I think it is PHP "leak" and it could be and should be improved in PHP core and it shouldn't force PHP architects to change their class-per-file design. It is bad that we are doing something in PHP what should be done in C in the core engine. best regards, Radek Alan Knowles wrote:

Chuck Hagenbuch wrote:

Quoting Davey <davey@php.net>:

If you care *that* much about performance, install a compiler cache.

The gist of the thread on the internals list is that compiler caches do *NOT* abate the penalty of using many include files, as the filesystem stat system calls are needed before you can tell whether or not a file was already included/compiled. So "use a compiler cache" is not a valid counter to Sebastian's point.

Not quite true.. - showing a typical scenario where I have 26 files. (about 22 of them PEAR or pear compatible library files) normal PHP takes ~0.33s per request. with APC takes ~0.07s per request. Assuming you could get rid of those stat calls, you may be talking about getting down to 0.05s.... As you can see, they do not really become a major issue, unless you are trying to squeeze ever last drop of performance out of PHP.. Anyway - If you check the thread on internals, you will see, that with some engine trickery, and APC, it is possible to get down to 1 or even no stats, for all those 26 files. * this does assume a few factors: - Never use relative paths.. - eg. design code to work without the '.' in the include path. - avoid symlinking on live servers.. - none of this will help you much, as soon as you do a database query :) This does need writing up in more detail in the RFC - as It took considerable thought - and looking at PHP source to understand.. Regards Alan

-chuck -- "Regard my poor demoralized mule!" - Juan Valdez