After reading OOP and Performance, Christopher Thompson rightly called my bluff (see the comments), triggering further discussion and forcing me to think harder.
In “OOP and Performance” I wasn’t trying to say anything absolute but rather describe a general hunch I’ve got. Although I singled out two personal examples, where the effect can, and was, written off as implementation detail, the hunch actually comes from general impressions and memories of trawling the source code of Open Source PHP apps, over the years, where they were written primarily with procedural code. And it’s not to say there aren’t any dog-slow OO apps out there – there most definately are.
Anyway, rather than waffle on further, I’m going to stick my neck out and say procedural PHP leads to slower apps (so I can get it chopped off ;)). The reason I’m feeling confident is that I think I’ve got a challenge which will help make things self-evident. Side note to any Perl / Python / whatever programmers – to an extent think this is specific to PHP, where a script itself does not define a separate variable scope and where classes are the only clean way to build abstractions.
So here goes. I’m going to define the input and output of a single script by providing the top and bottom. If you’ve got the time / interest,humour me and implement the section in the middle, once without using classes and a second time using classes / OO.
At the top of this script we have;
// This first dataset
$dataset1 = array();
for($i = 0; $i $dataset1 = array('a','b','c');
// This second dataset
$dataset2 = array();
for($i = 0; $i $dataset2 = array(
// This variable controls how the output is rendered
// Allowed values 'html','xml', 'plain'
$output_type = 'html';
(Your code goes in here)
…then at the bottom we have;
// output place in this variable
Of course there’s some rules and requirements…
– $dataset1 should be displayed to the user above $dataset2
– the script must be capable of rendering HTML, XML and plain text (whitespace formatted), depending the value of the output variable
– each dataset should be displayed with some kind of header (like a table caption) that tells the user what it is.
– you may not include any external PHP scripts – it must be all in a single script
– you may not read or write to any external files (in particular you can’t use templates or code generation)
– placing function names in variables comes under the heading “hack”, as does using PHP’s create_function()
– nothing should be output until the final statement: echo $result;
– try to code as quickly as possible – don’t spend too much time thinking about the solutions.
– don’t do any benchmarking until you’ve finished
Despite the rules, I think this example is fairly representative of the type of code that makes up big parts of typical PHP apps.
In fact I’m actually expecting someone to come up with a procedural solution which benchmarks fastest overall, but not by much. At the same time I think this will illustrate why it’s more likely that procedural code ends up delivering relatively poor performance.