Writing faster PHP code (1): require_once

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 ↓

#1 pp-layouts on 02.06.08 at 6:53 pm

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