KCachegrind

The other profiling analysis tool I want to talk about comes with a wealth of information, and a more colorful and detailed visualization then webGrind, which I covered in my last post.  As good as webGrind is, it only comes with a subset of the functionality of KCachegrind.  I will say this right from the start, KCachegrind is not a sleek user friendly interface. It has its quirks, and is what I would call antiquated, but what it shows you is worth the price of admission.

You'll need to install KCachegrind. For Linux, KCachegrind can be downloaded here.  Fortunately, there is a Window's port here.  Uncompress the files, and if you're using Wampserver, which I recommend, open up the wamp/apps directory and put the kcachegrind folder there.

The good news is you can install it as a menu item in your Wampserver menu, and thus start KCachegrind right from the Wamp menu.  To put KCachegrind in your Wampserver menu.  Open up wamp/wampmanager.tpl and go down to around line 130, or search for webGrind which should already be on the Wampserver menu.  The section where you want to add KCachegrind is [Menu.left].  Copy how webGrind is set up, and point to the KCachegrind.exe file.  Restart, Wampserver, and KCachegrind is now in your Wampserver menu.  Here's both the KCachegrind and webGrind entries for you.

Type: item; Caption: "KCacheGrind"; Action: run; FileName: "c:\wamp\apps\kcachegrind\kcachegrind.exe"; Glyph: 5
Type: item; Caption: "${c_webgrind}"; Action: run; FileName: "${c_navigator}"; Parameters: "http://localhost/webgrind/"; Glyph: 5

To run KCachegrind, you'll need data to visualize. It was originally built to use the data files from the data gathering tools Cachegrind and Calltree, and can be used with those tools today, however, its far easier to just use XDebug to create your profiler data file without the loss of any functionality. I covered how to create this file in a previous post.  Assuming you've generated several profiler data files, lets get started with KCachegrind.

Start KCachegrind.  You'll see the interface with no data.  Go to File->Open and go to your profiler data directory.  I mentioned in my profiler data post to call the profiler data files "callgrind...".  The reason is that KCachegrind will only, and I mean only, looks for files starting with callgrind. If you labeled your profile files something else, either go back and rename them, or set up your php.ini file to use the callgrind name, and run the profiler again. This is part of KCachegrind's quirkiness.

Another quirk to finding your files is how KCachegrind analyzes files, only the top file of a group of profiler data files will show in the file->open directory. A file entry in KCachegrind looks something like this,

"callgrind.out._.1399491693"

and thats it. How do you know what file to open?  KCachegrind will open all the subfiles under the top file once its loaded.  To make sure you get the correct file, look at the files in your profiler output directory in Explorer for the group of files your looking for, all the files in a group will end in the same number, open that number in KCachegrind.

The XDebug profiler is verbose with its profiler data files. It puts out many sub files under a main file.  WebGrind will open any one of these sub files, and you can then walk through your code a file at a time by loading each file.  On the other hand, KCachegrind opens the top file, and you walk through your code inside KCachegrind, which will open the subfolders as needed.

Ok, you opened a top profiler data file, lets look at what you'll see.

callgrindout629

Lots of colors, what's it all mean?

Well in the left hand panel you should recognize the same columns you found in webGrind. Each of these columns is sortable just like in webGrind.  The "Incl" stands for Total Inclusive Cost, and includes all calls.  The "Self" for Total Self Cost and just include with that particular call itself.  The "Called" column is how many times it was called, and finally the name of the function and its location.  This is all the information you can get with webGrind.  KCachegrind has more.

The drop down labeled "No Grouping" is a filter.  You can filter on either: ELF Objects, Extensible Linking Format, (executable, object code, shared libraries, and core dumps); Source Files; Classes; or Function Cycles, and just show each one of these alone.

If you click on any of these listings on the left, the value of KCachegrind becomes apparent. Clicking on a function brings the right upper and lower windows to life.  In the upper right tab menu, "Callers" lets you see what called the function you clicked on.  "All Callers" lists all callers of the function, and the callers that called the function, that called the function, in question, and so on back through the application hierarchy.  "Source Code" tells you where that function is located.  "Callee Map" is interesting, and shown in the above picture, it is a colorful usage graph of that function and every call to and from the function graphed in a rectangular blocks. The bigger the block the more time that function takes in the application.

You can drill down in the "Callee Map" and jump to that location in the code. But better yet in the lower right window tab menu, if you click on the "Call Graph" in the lower left tab menu, it will show you how the functions interlink with one another in a flow diagram.  There's a window within the lower left window that is overall map showing where you are on the screen itself. You can scroll around with your mouse.

Each "Call Graph" box is click-able, and will take you into that part of the application deeper. The "Callee Map" and the "Call Graph" are interlinked and as you move around and click, both images stay in sync. This way you can delve into the slow areas of your code, you instantly see the slow portion which takes up bigger sized boxes in the "Callee Map," and see a flow chart of that code in the lower window, including which section of that code are the worst performing.

As you can see the KCachegrind display far exceeds the webGrind display in functionality and color. The truth is I like them both, and there is a need for both.  With webGrind I can get to the actual source code quickly, but with KCachegrind, I can see how the code interacts with other code.  In the end, KCachegrind is worth the extra trouble caused by trying to figure out which file to open as I get a much better feel of what is happening in my code. Enjoy them both.