PHP Bug

Debugging and profiling in PHP

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.

Meet Xdebug

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.

To install Xdebug it’s very easy, just follow these instruction here, or if you are using mac OSX with MAMP read it here.

Codebug - Xdebug frontend for mac

Codebug – Xdebug frontend for mac

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.

Xdebug profiling

KCachegrind – Xdebug profiling

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.

Xhprof

Xhprof profiling image diagram

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.

Conclusion

These tools that I’ve shown you, are only PHP related, they won’t work with your javascript code, or you database queries. Some of these techniques I will write some other time.

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.

7 thoughts on “Debugging and profiling in PHP

  1. Permalink  ⋅ Reply

    Brian

    January 18, 2013 at 9:17pm

    What a helpful article! My days of print_r and var_dump may finally be over!

    Cubicle Ninjas

  2. Permalink  ⋅ Reply

    Codydmd

    January 19, 2013 at 12:31am

    Wow… wonderfull article which i was looking for,, thanks a ton!

  3. Permalink  ⋅ Reply

    Mac2k3

    January 22, 2013 at 10:26pm

    I don’t know if you know it or not, but there is a sublime text 2 plugin out there, which allows you to use xdebug debugging from within Sublime Text 2. I haven’t got the url at the moment, but it shouldn’t be hard to find.

  4. Hey There. I discovered your weblog the use of msn. This is a very neatly written article. I’ll be sure to bookmark it and return to read more of your useful info. Thanks for the post. I’ll certainly comeback.

  5. Permalink  ⋅ Reply

    Tim Kelty

    May 31, 2013 at 6:57pm

    I just started using Codebug and am loving it.
    I tried to use MacGDBp for a long time but could never seem to get it working quite right.

    I also use Sublime Text. What would be great is if I could set a break point in the gutter of Sublime Text and have it show up in codebug.

    I saw this: https://github.com/Kindari/SublimeXdebug, but that’s seems to be a full client right in ST. I would love to keep using Codebug, but just be able to set breakpoints in ST (without adding xdebug_break(), that is)

Leave a Reply

Your email will not be published. Name and Email fields are required.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>