What you really want to watch instead is the size of all code included per request. Therefore, a 600KB php file roughly cost 6ms, or about 1ms when using an opcode cache. 1µs for 100 EMPTY File includes, w/opcacheĥms for 100 EMPTY File includes, no opcacheħms for 100 32KB File includes, w/opcacheģ0ms for 100 32KB File includes, no opcacheġ4ms for 100 64KB File includes, w/opcacheĦ0ms for 100 64KB File includes, no opcacheĢ2ms for 100 128KB File includes, w/opcacheġ00ms for 100 128KB File includes, no opcacheģ8ms for 100 200KB File includes, w/opcacheġ70ms for 100 200KB File includes, no opcache
#PHP RUNNER COST MAC#
For a better idea of what those cost are, here are test results I conducted on a 2010 Mac Mini Server, with a 10,000 RPM drive, running PHP 5.3 with an optimizer enabled eAccelerator opcache. The real cost come with the size of your files, and what PHP has to parse and/or compile. And using an OpCode cache makes that cost irrelevant. So the cost savings of including a larger php file containing 100 classes, as opposed to 100 separate file includes, is only about 5ms. 100 file includes (with empty files) costs about 5ms and no more than one microsecond when using an opcache. The cost of the function itself is quite negligible. I have conducted some tests on the various cost(s) of php include() which I'd like to share, as I see many programmers or CMS platforms overlooking these pre-runtime php costs. But if you're not, I personally wouldn't worry about it. Now, if you have facebook traffic levels, it may be worth investigating further. I personally would keep all the classes in separate files and make my life as the developer easier rather than making one giant monstrosity of a file. Maintainability will suffer with one large file since it's harder to work on multiple classes at the same time (tabs in an IDE become useless). However, more is at stake than raw performance. So the only way to know for sure on your platform is to test. The exact break-even points will be 100% system dependent (how fast is your disk I/O, how fast are your processors, how much memory, etc). I would imaging that it would be somewhere around the 50% mark (where if you're using less than 100 classes in any one request, autoload).Īnd using APC will likely shift the breakeven point closer to less classes (so without, 100 classes used might be the breakeven point, but with it might be at 50 classes used) since it makes the large single include much cheaper, but only lowers the overhead of each individual smaller include slightly. Where the cutoff lies is really system dependent. If you use all 200 classes, including the large file will be significantly less expensive than including 200 small files. If you only use 1 class, including the large file will be more expensive than including a small class file for that individual class. Let's say you have a large file with 200 classes. Basically, the cost of including one big file depend on your usecase.
0 kommentar(er)
