When it comes to larger projects than yet another WordPress blog, refactoring and additional memory optimization are required to move the project in the right direction.
Cachegrind is a GPL profiler for applications. It simulates how the program interacts with the architecture – including cache layers from the standard configuration of the modern systems and the CPU cache types that are normally presented. This allows for profiling applications on a lower level, including:
- the time for calling a function/initializing an object/etc
- the number of calls for a given function
- stacktrace of calls
And much more. In essence, it’s a visual representation of all possible bottlenecks in the application that could be optimized – like reducing the execution time of a function or the number of calls to a given function when not necessary.
For example, here there is a report of running my localhost’s phpMyAdmin page with Cachegrind:
Cachegrind is Linux-based profiling system that runs on most popular Linux stacks and could also be integrated with Xdebug for profiling. After the proper setup, my call for generating the cachegrind log file is:
http://localhost/phpmyadmin/?XDEBUG_PROFILE=1
When set, the Xdebug configuration in the php.ini file needs some guidelines on how to run the profiler – I prefer to do it manually with the XDEBUG_PROFILE query argument as it doesn’t have to run the profiler and generate the log for every request. In my php.ini:
xdebug.profiler_enable_trigger = On
xdebug.profiler_output_dir=”/tmp/cachegrind”
The cachegrind log file is not exactly pretty or visible. One could view the graphs throw Webgrind or KCachegrind (the latter is a KDE library but it still could be set in a Gnome-related box if you install several KDE dependencies).
More on Xdebug and profiling here + a few more samples here.
