Monday morning. Your previous project just wrapped up, and they are going to assign you a brand new one. They even promised you the lead on this project. Who said Mondays couldn’t be great?

A few hours later and you are staring at the most dreadful code you have ever seen — controllers of more than a thousand lines, PHP that injects jQuery in the views, raw SQL statements that could challenge a Dostoyevsky novel in size. The list goes on and on. This Monday is going to need a ton of coffee.

The previous few lines might sound very familiar to you. You might even be working on a project like this at this very moment. If that is the case, … lucky you.

Why do these horrible applications exist? 

Most applications don’t start like this. As you know, greenfield applications start full of hopes, dreams and rainbows. A new business idea gets launched. It does something small, pretty good. People like the application. They like it a lot. More and more customers flock to the application. You excitingly add more functionality to your small idea. Soon, one of your more prominent clients asks for a very valid use case.

Hmm, you haven’t thought about this particular flow in the application. To be honest; the application doesn’t support it. However… it’s a big client, and it’s a great idea. You know what, this small little hack won’t make the difference. We’ll document it, so everyone knows about it.

Fast forward a few months. You have a dozen developers working for you, and your Kanban feature board is filled to the brim. The strange thing about the board, however, is that most of the features on that board don’t come from your hand, they come from customers. Moreover, they all want concrete things very tailored to their workflows. That little hack that’s been made a few months ago is now not even considered a hack anymore; it’s just how the application works. Moreover, if you take a step back, most of the application is now a collection of these small little hacks.

You might think that this is a horrible product, and from a code perspective you might be right. However, from a business perspective, this is a vital process. The product has a ton of customers, and they are invested enough to want to tailor it to their workflows and they even reach out to you with suggestions. Granted, not all of these suggestions are great, but they wouldn’t come forward if there weren’t a need for them.

However, now where does that leave you, It’s entertaining to have a company with many customers, but at the end of the day, you’re still the one that is in the trenches of despair.

Not necessarily; Having a product like this tend to generate income. The most significant part of that income is invested back into the project. Once the legacy code hampers the production of new features or generates too many bugs, the discussion surrounding refactoring parts of the code tend to start getting more and more speed.

Once you start refactoring, you suddenly notice that you have so much value in front of you — a ton of use cases already implemented, a wealth of user behaviour and data, metrics and most important of all: the budget and infrastructure to match.

Most refactorings tend to start with the question from management that is frequently a variation of: “what are the worst parts of the application, and how can we make them better”. This sentence is poetry to a developer’s ear. A great chance to go over the entire application note down the pain points, look at technologies that might ease trouble, have lengthy discussions with colleagues about the architecture of the pesky service classes. Not only are you going to learn a ton on the technical side of things, socially you’re going to improve in ways of persuasion and proposing ideas.

After a while, the most significant part of the spec will be done. Moreover, I can guarantee you that you’ve never been so excited to work on a project before. You can now look at the project and see a road to be walked, where before it was just an end to a means.

Now comes the tricky part, refactoring one of those huge files. The first time you read over the class, you might get some doubts about this whole refactoring stuff. Luckily you stick to your means of attack and write your first end to end tests. Once you’ve established a safety net, you regain a big part of your courage.

Ok you think, this piece of code I might be able to extract to a separate class. You write the unit test. You extract the code, and everything is green. Ok, great start! Let’s do it again.

A few hours later you stare at the construction you’ve made. It’s a vast improvement of what it was before (every single indentation you fix is an improvement), but looking at the loose classes, you can see some definite improvements still. You could leave it as it is, and that would be great, or go further. Either path you chose, at one point you’re going to create a PR, and sit back and stare at the diff screen of your favourite git hosting service … what a beauty.

Working on applications like this is all about responsibility. Every decision you make as a team will impact you in the future, in a good way and sometimes in a not so good way.

This kind of pressure might sound like a burden, but in reality, it is indeed a blessing. It forces you to slow down and think about your actions as a team. Should I write a test for this? The answer is going to be yes, cause once it has a test, it’s going to part of the test coverage for maybe years to come.

So that’s the beauty of legacy code: You get a rough stone that you can shape into a gem. The pressure of delivering new features won’t be lower on a legacy application over Greenfield, but management often understands the need for refactoring and architectural meetings better.

Moreover, all the technologies and paradigms learned in the refactoring of legacy code are invaluable when you move on to Greenfield projects as you now have the context for the need for value objects, testing and decoupling.

So yes, if you’re about to start on a legacy codebase. Lucky you. You’re about to have one hell of a ride.

Controllers of more than a thousand lines, PHP that injects jQuery in the views, raw SQL statements that could challenge a Dostoyevsky novel in size. This Monday is going to need a ton of coffee.

We've all been there before, you submit a pull request and moments later you get a comment like: "Hey you should use a native function here, they are so much faster" or "You can declare this final, that way we save some processing power".

It's great that we as developers keep an eye on this, but how true are these thing. And are they still a thing in newer PHP versions?

Time to put some of these "good practices" to the test. I've selected 10-speed tricks that I've picked up over the years and we're going to check how relevant they still are in PHP7.2.

So how are we going to test this? I've set up a small project that we are going to be running natively (no Docker, no vagrant) in MacOs (version: 10.13.5). The PHP version is the latest version currently on brew (PHP 7.2.8).

The benchmark itself uses PHPBench and we are going to compare each "trick" to its standard alternative. They are separate methods that each will be running 1000 times over 5 iterations. So that means we will run each test 5000 times grouped over 5 results. That way we can minimise deviations and extract meaningful results.

But before we begin, please a word of warning. We are going to zoom in on these claims. Some of these results might seem pretty high but that is only because we only run very small pieces of code. The results might not be that extreme in your day to day code.

Are single quotes faster than double quotes? 

Let's start out with a classic. As single quotes are encouraged by PSR we all might be getting some small speed bonuses without knowing it. We will test with this code:

PHPSpeedQuotesA.php

PHPSpeedQuotesB

Turns out that single quotes are about 5% slower in this test.

Sometimes we like to use JSON or XML to setup validation or config files. Most people like to use JSON over XML due to readability reasons. But is it also faster?

A quick word of warning here, we will be using the native xmlrpc_encode en xmlrpc_decode functions. These are very experimental and not fully implemented. We could be using packages for this, something I would certainly advise in real projects, but that would skew the results too much (as we need to load them in etc). So here is the code:

PHPSpeedQuotesJson.php

PHPSpeedQuotesJsonResult

The native experimental functions that deal with XML are way slower in our tests.

Using loads of layered objects is way slower? 

This one will be a bit messy to display. We are going to new up some classes and send the parameters down 3 layers. There we execute the same function as we otherwise would.

I think we all know that the new-ing up of classes will lose us some time, but let's see how much time we lose.

PHPSpeedLayerTest.php

PHPSpeedLayerResult

Unsurprisingly the new-ing up of classes takes some time. In this case, it comes down to about 25% slower. This obviously doesn't mean you shouldn't be using classes anymore. Personally, I will always prefer maintainability over speed.

Native array functions should be faster than loops, right? 

This is a classic. It's said that native array functions are faster than for each loop because they are native C functions. This is the code we will be running:

PHPSpeedNativeTest.php

I'm going to be totally honest here and say that I've run this test a few times now, cause I couldn't really believe the results:

PHPSpeedNativeResult

Turns out that in this test the array_map method is slower than the foreach. This probably has something to do with the anonymous function.

$row[’id’] is 7 times faster than $row[id] ? 

I've never heard of this one. Apparently, it's a thing:

PHPSpeedQuotedArrayTest.php

Turns out it doesn't really make a lot of difference, at least not in the 700% range.

PHPSpeedQuotedArrayResult

The string fetching is even marginally slower in our test by 2%.

Error handling is an important part of any application, but it is said you should be a bit wary of using extensive amounts of try-catch blocks. Time to put it to the test.

PHPSpeedThrowTest.php

PHPSpeedThrowResults

Unsurprisingly we lose some time on the errorHandling. But personally, I would always recommend having more error handling over having less.

Most static analysis tools tend to either complain about unused vars or straight up to remove them for you.

As unused vars in your code serve no real benefit, it doesn't really make sense to keep them. That said, let's take a look at the cost.

PHPSpeedUnusedVarTest.php

PHPSpeedUnusedVarResult

So it is about 7% in our tests. But as you probably know, there is no real reason to keep those vars around.

Magic methods are slower than regular ones? 

I love to use value objects. And in those objects, I normally use __toString() to cast the object to a string. But I've had some remarks that you should just make them yourself to have a speed boost. Time to take a look at that.

PHPSpeedMagicTest.php

PHPSpeedMagicTest

Turns out magic methods are indeed a tiny bit slower, at about 12% in this test.

Final classes should be faster than non-final classes? 

A friend of mine (the very talented Wouter Sioen) declares his classes final on the creation and only changes it when they really need to be extended.

I'm pretty sure he does that due to OOP reasons, but maybe it's also a bit faster. That could make sense right?

PHPSpeedFinalTest.php

PHPSpeedFinalResults

In our tests, it is slightly faster to use final

That said, I think it a good thing to do anyway.

Do comments have an impact on your code? 

Ok, this is the last one. This has brought so many discussions in the past. Docblocks over return types, code should be self-documenting, ... You've seen the discussions before.

PHPSpeedCommentTest.php

PHPSpeedCommentResult

Some of these tests might surprise you, some might not. That said, please don't stare yourself blind at the results here. Speed is just one part of software development, and I personally think marginal gains don't out weight good developer practices.

At least you left here with some fun facts about pop stars.

We've all been there before, you submit a pull request and moments later you get a comment like: ''Hey you should use a native function here, they are so much faster'' or ''You can declare this final, that way we save some processing power''

Frederick Vanbrabant's

delirious rantings

A love letter to legacy projects

What performance tricks actually work