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.

On the SitePoint PHP Blog, Harry Fuecks has posted an interesting bit asking about a PHP frontend for Xdebug profiling, specifically for the 2.x version's output.

Several of the comments either ask why he would want to write it when the two tools he mentions work just fine or a few links to scripts out there that already do this sort of thing. If you've been looking for something like this, definitely check out this post - there's a few resources in there you don't want to miss.