New on PHPBuilder.com today there's a tutorial on profiling your applications with the help of XDebug and the KCacheGrind tools.

[Eventually you'll want to seek out and resolve any bottlenecks.] Which brings us to the question of how to even go about determining which parts of an application could conceivably be optimized. One common approach involves using a profiler such as Xdebug, which can analyze your code and produce performance reports. These reports can then be reviewed within a profiling visualization tool such as KCacheGrind. In this article I'll show you how to use Xdebug and KCacheGrind to begin profiling and analyzing your PHP-driven Web applications.

He starts you from the beginning - installing both XDebug and KCacheGrind (unix-based, if you're on Windows try WinCacheGrind). He gives an example of a profile report based on a Zend Framework application and an example call graph output (as well as how some caching can help things quite a bit).

On the Affinity Bridge blog today there's a great post looking at the use of Xdebug and KCachegrind to pinpoint bottlenecks and possible refectoring points in your code in a bit more visual way. They use an example from their own development - a script that took around twenty minutes to run.

By reducing the number of queries, making small code optimizations, and properly indexing and keying the legacy database we managed to cut the time to 10 minutes'"still we were way off target. To get a better look at what was going on, we thought it would be great to install Xdebug and take a look at it with KCacheGrind.

They show you how to get the full setup installed (on a Ubuntu system) - the LAMP stack, Xdebug and KCacheGrind. Complete commands to install, configure and run a sample debug session are all included. Sample outputs from the KCacheGrind software are there too: code structure, execution times.

Douglas Clifton has a quick new post to his blog looking at an invaluable tool in application development (and not just in PHP) - cachegrind output.

Valgrind is a entire suite of open-source tools, including basic debugging, profiling, and more advanced techniques such as threading, memory management, and leak detection. For the purposes of this article, I will focus on Cachegrind, and in particular within the domain of Web applications. Although there are a number of developers contributing to Valgrind, Julian Seward is the original designer and author.

He talks about the cachegrind software and the PHP-based profiler that can create these files - XDebug. He also includes a list of a few of the cachegrind viewers including KCachegrind and Webgrind.

In a new blog entry today, David Coallier has posted about two new offerings that are in the works for a web-based frontend to XDebug:

For quite a while in the PHP Community (And even myself) I have heard people asking about either an online tool to work on cachegrind output files or a cross platform tool that would have the ability to do what KCacheGrind does on Linux but for Windows and OSX.

He mentions the origin of the idea for a cachegrind app as a part of the Google Summer of Code (that did get accepted and will be worked on by Chung-Yang Lee). The other, Webgrind is an independent project from the other but looks equally as promising.

Check out Vinu Thomas' thoughts on the matter too.

Andreas Gohr has a new blog post today that talks about a way to really get to know your code better - use XDebug to see it from the inside out.

Xdebug is a PHP extension which helps you to understand, debug and profile PHP. It can help you to find bottlenecks or give you an quick overview what happens in code you aren't familiar with, yet.

The post gives a brief overview of the installation of the extension (building a shared module) and shows how to get started with profiling an application. He talks about the cachegrind tool you can use to parse the results and the kcachegrind app that will make the results a bit more visual.

As a bonus, he also throws in a bit about function tracing - picking out each small bit of functionality in the code (the function/methods) and gathering stats for each.

The Zend Developer Zone has posted the theird part of their series (by Stefan Priebsch) about working with XDebug in PHP to profile your applications.

In this week's issue, we will have a look at profiling. Profiling is a feature that seems to be similar to trace logging at first sight. Profiling logs, however, are not meant for human readability, and are not meant to visualize the program's control flow, but provide the data for a statistical analysis of the program run.

He includes an example of the profiling log his XDebug setup is generating and gives the settings you'll need to make a log of your own like php.ini settings to start it up and name it/place it where you want it.

He also talks about the method to get something useful out of the profiling logs - using WinCacheGrind or KCacheGrind to get an overview of what's going on "on the inside" of your application.

Stefan Reuter has a very quick example of a method for profiling your PHP applications with Xdebug and KCachegrind.

Ever wondered where your PHP applications spend their time? [...] We wanted to gain performance insights of a newly developed application based on Zend Framework to spot areas worth receiving some fine tuning. We did not want to modify the application for that purpose so I had a look at the options available for PHP.

The resulting combination of XDebug and KCachegrind to grab the stats from the application and create great output images/reports to help make locating the problem a snap.

Sebastian Bergmann has posted about a bottle neck in the PHPUnit unit testing software for PHP:

Now that collecting code coverage information is not slow anymore (as of Xdebug 2.0.1), PHPUnit's report generation code (PHPUnit_Util_Report_*) has become a bottleneck.

There are several images included in the post (output of KCachegrind):

• generation at revision 1473
• generation at revision 1475
• generation at 1486
• generation at 1488

On the Internet Super Hero blog today, there's this new post with a sort of retraction of some of the previous comments they've made on the mysqlnd drivers - really more proof that "mysqlnd can't do wonders".

Lastly, I've been blogging about positive performance related feedback on mysqlnd. Whenever I did so, I got some positive feedback - for obvious reasons: I was posting good marketing news. [...] As much as I'd love to, I can't stand behind a simple statement like "mysqlnd makes your applications faster". You must not assume that each and every application will profit from mysqlnd.

His target of choice was WordPress which he ran through a testing cycle with JMeter (a load and performance testing tool). In the end, though, using the mysqlnd drivers and the regular drivers didn't show much of a difference at all. To figure out why, he uses XDebug, APC and KCachegrind to work through where the issues might lie. Unfortunately:

I was not able to see any mysql_*-function in the call graphs. The reason is that the mysql_*-functions do not contribute to the overall runtime of this application in a major way.

A new post to the SitePoint PHP Blog today (from Paul Annesley) looks briefly at how, with the help of XDebug, you can make your applications lighter and faster.

So we've got potentially slower code, and we can no longer just open up our simple PHP script and follow its execution from the top of the file to the bottom. How do we figure out exactly what's going on inside?

He doesn't go through the installation of XDebug, but he does give an example (complete with screenshots) of how to use it in conjunction with two other applications - WinCacheGrind for Windows users and KCachegrind - to work with the output XDebug produces.