When I started working as a web developer, PHP was the first language I learned that was 100% web oriented.
Back then I believe it was PHP3 or something like that. At the time, PHP was pretty new to the web, PERL was the main denominator.
PHP today is hated and loved, and I’m not going into that path here, I’m very programming language agnostic. My mantra is “use what’s best for the job”. However, back then PHP was getting lot of traction, mostly because it was very easy to work with and to setup/deploy. Nothing, even today, beats the LAMP stack.
However, with great power, comes great responsibility. And in the beginning PHP was like that cool friend you had when you were a teenager, fun, irresponsible, doing fart jokes and it was easy for us to get along. The thing is, PHP grew, it’s user base grew as well, and today PHP is no longer that C-glued scripts. PHP is being used on entreprise level, on high-scaled websites, it’s complexity is also much bigger. Now we have amazing frameworks like Symfony, Laravel, Codeigniter, Kohana, Yii and other.
These frameworks help you build better and faster websites, but they can be quit complex internaly. So we need tools that help us understand how they work, how we can improve our code optimisation and so on.
In this article I’m going to show you some techniques I use to debug and profile PHP code.
Why var_dump(); sucks
First, var_dump(); it’s a cool function, it allows you to print out an object/array/variable content. However it’s being wrongly used as a debugger and to test things out. It’s amazing the number of developers that rely solely on this function and others like “print” or “echo” to test their code.
Why it sucks? Because it takes something out of context. You will never know what things got triggered along the way that make that variable hold its content.
Say for example your have a variable called $foo, that keeps returning false, when it should be returning true.
Using var_dump, you don’t get any solution to your problem, you only know what’s wrong, not how and why it went wrong. It’s like you are a detective and you know the victim is dead, but you don’t know why he’s dead.
You might say: “well, I can just put a few prints in the lines above that variable where I think it might be changing it”. Yes that might be true, but it’s still a trial and error thing. Catching bugs this way it’s a pain in the ass.
There’s a better way.
What’s Xdebug? Xdebug is PHP debugger module, it allows you to step through your code and watch it in real time how your code is being processed by PHP interpret. With a debugger you are Neo from the Matrix, you can stop the time and see exactly how things work. How can you not want to be like that ?
By “things work”, I mean, you can literally see what function are being called, how and when variables change their values and what caused that change. You can even change a variable content in real-time. Beat that var_dump().
You can specify at which lines you want Xdebug to stop the code so in you can inspect, or you can just type “xdebug_break();” in your code to emulate a breaking point.
Using Xdebug is even more fun when you realize that you can do it remotely, from your hosting server, as long as you have a local copy of your code files you can set up breakpoints remotely.
It still beats me why PHP developers don’t use Xdebug.
I love Xdebug so much, that I even built a Xdebug client standalone for the Mac called Codebug. I created it because there weren’t real stable solution unless you wanted to use an IDE like PHPStorm or Netbeans, which in my case I didn’t. I’m in love with Sublime Text.
But if you use any of these IDEs, they already include a Xdebug frontend.
If you use PHP as a professional, you need to have Xdebug installed. Trust me, you won’t go back to var_dump() anytime soon.
Also, you can use Xdebug to learn how some class or function works. It’s a good learning tool for code you don’t exactly know how it connects.
But Xdebug isn’t just about code debugging, it also let’s your profile your code.
What profiling means is that, it allows you to see what parts of your code are using more memory, calls, and response time. This is a really useful add-on.
However, I can recommend something better for profiling.
Say hello to XHProf
XHProf was developed by Facebook development team. So you can imagine the complexity that is Facebook, and why they build this.
What this module does is to tell you exactly what parts of your code are decreasing your application performance.
Your page is taking 10 seconds to load and you don’t know why ? Try running it through XHProf.
This is a must-have tool if you care about your application behaviour.
It highlights the most memory/time consuming functions or classes in a red colour, and what was the origin of the function call in yellow, so you a complete path on how to get to that code hog and fix it.
It’s very easy to setup and you can turn it on and off whenever you need.
I don’t know of any other tool for PHP that works this great.
Again, I highly recommend it. It’s an amazing profiling tool.
Web development is getting more complex each day, and we need tools that free us from doing boring tasks and we need tools that, not only helps us, but that actually makes us better developers by approaching problems in a more efficient way.
I hope you learned something new from this, and that this might help you work better with PHP.
If you have more suggestions or tools for PHP let me known on the comments below.