Gotten to the point where adding that next caching for some database query simply stopped being helpful?
No clue why your crappy WordPress plugin takes up 50% or more of the page load time, even though you cut the database queries down to next to no query time?
This is for you …
When to Micro-Optimize ???
Easy … whenever there is no other way out of your performance problem.
Sure hardware is a ton cheaper than developer time … but every now and then your project simply does not allow for that hardware upgrade for whatever reason …
Shipping your product to a bunch of customers maybe?
Already running the fastest CPU out there?
Your developers love you and work for free?
… so many possible reasons for why you might be reading this …
So let’s get to it …
No Free Lunch …
So you did it … your static code analysis tool is finally happy. All methods are less than 40 lines or whatever arbitrary maximum method length you though will make your code look nice.
Everything is nicely encapsulated in a million classes, every action your code takes fires of a trivial to understand series of small objects interacting all nice and readable … unfortunately your customers started to brutalize Google for a leaner competitor meanwhile … those ungrateful simpletons … not showing the least bit of appreciation for your code quality, for your readability … not even for your separation of concerns …
What did you think … that the load time of your site is just those darn database queries ?
… or maybe those darn regular expressions ?
… or is it all in your caching now? All those serialize/unserialize operations getting the best of you?
Sure those things are slow at times … we’ll look into those some other time though.
For now, let’s try to find out how much we’re actually paying for all those tiny functions, methods, objects and redundant variables that make everything so nice and readable.
… those aren’t free … not at all.
Getting down to it …
Step 1: So not free eh? How much are they then? ( Gathering Data )
Well it depends … let’s gather some data I guess …
Since we might be dealing with the case of a broad and very heterogeneous user population, lets gather that data across multiple PHP versions.
While we’re at it, we can also stop you from using all that crazy profiling I suppose … so lets also play with XDebug while we’re at it …
So multiple setups … good thing it’s 2015 and we have Docker to play with now.
So help yourself to some working docker daemon and the code we’re gonna be using here.
So once we have that code, let’s run it. Since we’re mostly concerned with the effects of inlining ( or rather not inlining ) things here. That .sh file seems like a good start.
Bam! … that’s enough data for one day I guess …
So how did we do that? … we just ran this script leveraging Docker’s awesomeness.
Mount the current working dir containing the inline.php test script into various docker containers and execute it in exactly the same way on each of them.
The test script itself just does one simple thing in various ways, it concatenates the strings ‘a’ and ‘b’ a bunch of times and depending on the test either very directly or buried deep in the stack …
So, what can we learn from this, let’s see …
Step 2: … WTF is This ??? ( Making Sense of the Data )
Step 2.1: Turn off XDebug …
Without even going into the details of each test run, you should be able to see why XDebug is probably the worst thing to have running while optimizing performance.
It significantly skews the relative performance of various solutions to the same problem.
A few examples from the above data for PHP 5.6:
Using redundant local variables comes with a 1.43/0.86 ~ 1.66 times slower execution for concatenating ‘a’ and ‘b’ when running:
instead of outright running:
… when XDebug is not loaded.
Load XDebug and the advantage of removing those redundant variable assignments goes down to 6.17/4.91 ~ 1.26 speedup/slowdown.
The trouble with XDebug is not that it slows down overall execution, the trouble is it skewing relative performance relative to production systems! Either avoid using its profiling when micro-optimizing or at least be mindful of this effect!
Step 2.2: Understand the data …
Step 2.2.1 Redundant Local Variables are Slow and Hard to Read
Lets not get into the readability thing here … this is settled anyhow … You use the variable only once ? So why use a variable ? Why would you want me, the poor dude having to read your code, to be forced to understand that you’re just using that variable as a long-winded way of adding a comment? You don’t need to save that data to anywhere, you’re only using it once … so please make the code tell me that when I read it …
Also … apart from me being able to better understand your code … more importantly your PHP interpreter will be able to better understand it …
Just by the numbers the above example of adding pointless variable assignment to the concatenating of those two strings comes with a slowdown, depending on the PHP version of:
PHP 5.4: 66%
PHP 5.5: 68%
PHP 5.6: 66%
PHP 7.0: 139%!
So why is that so … everyone on StackOverflow tells me that these assignments are ‘optimized away’ anyhow?
First off … guess who does that optimizing and needs time for it … yes your CPU …
Second of all … PHP is constantly optimizing things behind the scenes and getting ever better at it as time goes by. Now it’s relatively trivial to see ‘a’ . ‘b’ and figure out that this will always come out to ‘ab’, reserve the respective amount of memory and get all the other crazy weird things behind the scenes right. But thing about optimizing $a . $b … there’s nothing to optimize there unless the interpreter knows what $a and $b are beforehand. It cannot know this without executing the code though for obvious reasons … ( cough … Halting problem )
Good thing you’re a human and know what’s going on in your code better than the machine … be so kind and tell it all that you know as directly as you can. It might reciprocate and help your customers as quickly as it can at some point down the line :)
Step 2.2.2 Function Calls ain’t Free …
The next thing to understand is, that function calls are not free at all compared to just running code line by line. Someone has to find out and keep track of what function means what …
Sure this is all in some hash table with very fast lookup and very strong scaling behavior … then again if you do this a few thousand times it does add up …
So lets start out with the numbers on how using some function like
compares to just good old …
Depending on the PHP Version the slow down comes out to:
PHP 5.4: 65%
PHP 5.5: 67%
PHP 5.6: 73%
PHP 7.0: 118%!
Again … the newer your PHP version the more of the under the hood progress made on the interpreter is wasted by adding additional function calls that mess up optimizations.
This is not to say that you should get carried away creating monstrous functions spanning hundreds of lines, rather see if that small function inside some long loop really needs to even be a function/method ? Maybe it can be inlined since it’s used in one spot only anyhow?
Also for even more obvious reasons … at least stop doing this to your coworkers:
Seriously … why is this still happening in so many projects on this planet? … Sure sometimes it’s just an outright compatibility/needing that alias thing … mostly this is just stupid though ..
Step 2.2.3 Objects do cost a lot!
Given you know about the expenses incurred from redundant variable assignments and function calls this shouldn’t come as a surprise to you,
object instantiation and class methods come at a significant cost. More on this some other time, just keep above numbers in mind when coding your long loops.
Something like the below example ( obviously way over the top ), surely won’t be an issue used like 10 times throughout your app.
Use it in that 10k iterations loop and it will show though …
Step 3: Uff … won’t do it again … Promise! ( Avoiding Overhead when it matters )
Just knowing the above should give you a strong starting point to optimize away some of the demonstrated overhead from your code where it matters.
Instead of going overboard with these things though … keep your code clean, keep things modular … when the time comes to speed up those long loops or whatever, you’ll find them in no time.