This is the first in an occasional series on writing faster executing PHP code. Eventually I’ll finish the test suite I started about this time last year to show the demos live on this website complete with source; for now it’ll all have to go in a weblog entry ![]()
First up is require_once. A nice convenience function, is it worth the speed hit involved?
h2. Testing criteria
To test the speed of the function calls the file I include is as small as it could be:
bc.
This prevents the test from being muddied by the compliation speed of the PHP code. However, you must remember that this does mean if your hosting provider doesn’t use a bytecode cache, then you most likely won’t appreciate any speed-up caused by optimising your code in this way.
h2. Results
h3. Using require_once
| time index | ex time | % | |
| Start | 1072025702.37311600 | - | 0.00% |
| Before re-include | 1072025702.37346400 | 0.000348 | 71.17% |
| Stop | 1072025702.37360500 | 0.000141 | 28.83% |
| total | - | 0.000489 | 100.00% |
h3. Using require and a defined constant
| time index | ex time | % | |
| Start | 1072025698.95371700 | - | 0.00% |
| Before re-include | 1072025698.95406200 | 0.000345 | 91.03% |
| Stop | 1072025698.95409600 | 0.000034 | 8.97% |
| total | - | 0.000379 | 100.00% |
As you can see, using @require@ produces over a 3x speed-up compared with @require_once@. But *what happens if we use a bigger class?*
h2. Second Experiment
I tested this by including “PEAR’s”:http://pear.php.net DB class into the script (change source code references from test.php to DB.php; and the constant ALREADY_INCLUDED to DB_OK) as this was the biggest class I could easily lay my hands on.
_Important:_ DB.php did not have to include PEAR.php as Benchmark/Timer.php had already done so - therefore less code was included than I first thought. Still, it’s already a pretty hefty chunk ![]()
h2. Results
h3. Using require_once
| time index | ex time | % | |
| Start | 1072026680.34563400 | - | 0.00% |
| Before re-include | 1072026680.35255600 | 0.006922 | 96.96% |
| Stop | 1072026680.35277300 | 0.000217 | 3.04% |
| total | - | 0.007139 | 100.00% |
h3. require and defined constant
| time index | ex time | % | |
| Start | 1072026688.33523100 | - | 0.00% |
| Before re-include | 1072026688.34217500 | 0.006944 | 99.21% |
| Stop | 1072026688.34223000 | 0.000055 | 0.79% |
| total | - | 0.006999 | 100.00% |
This time, approximately a 4x speed-up over using require_once for the second time. Are 150 microseconds worth saving? Maybe if your site is heavily frequented; but the effort’s probably not worth it otherwise.
h2. Rating
Speed-up: 1
Ease: 4 but makes more hassle
Is this change worth it? Certainly not if you aren’t using a cache, or if you’re using huge classes
Source code used can be viewed in the extended entry
h2. Code used
h3. require_once
bc. start();
require_once ‘test.php’;
$timer->setMarker(’Before re-include’);
#for($i = 0; $i stop();
$timer->display();
?>
h3. require and defined constant
bc. start();
require ‘test.php’;
$timer->setMarker(’Before re-include’);
#for($i = 0; $i stop();
$timer->display();
?>
1 comment so far ↓
Hey, thanks dude! I was just wondering if my require_once-s slow down my code… Well, I’d better quit such thinking, because my hands are starting to shake when typing preg_….
I’ve noticed, my code is relatively simple enough to use all kinds of magic in it. And what’s not quite clear to me: generation times of the whole website vary. Once it’s 0.1s, once code reports it’s 10s. Though I didn’t seem to me like whole 10 seconds. Maybe my benchmarking is wrong? Maybe it’s because of varying server load?
Leave a Comment