SamplingProfiler v1.7.0 is now available, you can get the zip and release details from its changelog page.
As announced last week, the changes are a fix for a bug that could drastically affect the execution speed of the profiled application when relying on MAP files for debug information, if you were hit by this bug, things should be like night and day with this version (and hopefully I didn’t break anything else in the process…).
The other main addition is that of the real-time monitor, which with default parameters and when activated locally should be reachable at http://localhost:880/ (see the help for other details). The monitor is still at an early stage, and only provides real-time information, as time allows, it may grow to offer more profiling and debug features.The current monitor page is a rather basic html page that is fully refreshed periodically, which isn’t very pretty at the moment… an XML version of the real-time information is available at http://localhost:880/sampling.xml, if you come up with a pretty AJAX-based version before I do, feel free to contribute it
MapFileStats v1.2 is now available for download, it fixes reported issues and introduces a few minor improvements, such as using the ability to abort search paths scans and remembering MAP File and Search Paths options between executions. You can find the complete list in the changelog.
In other news v1.7 of SamplingProfiler should be ready “soon”. It fixes a bug that could drastically reduce the profiled application’s execution speed (when using MAP file information), and will introduce a “Real Time Monitor”, which allows to see what a profiled application is doing in real-time (unsurprisingly).
The monitor is actually a simple web server embedded into the profiler, so you can monitor an application that is run locally or on another machine. Real-time data will be accessible both as a bare-bones HTML page, or in XML form for the AJAX freaks out there.
SamplingProfiler run results can be saved to .spr files (Sampling Profiler Results) and later reused for comparison purposes, or for merging, one of the less obvious features of the profiler.
You can merge results by right-clicking on a results tab and selecting… “Merge results”, oddly enough. After this, the samples will be aggregated across the runs you selected, hopefully providing more statistical accuracy.
This can be particularly useful when analysing the results from multiple runs, collected from multiple users in the field via SamplingProfiler’s silent mode for instance. It can also be useful if you collect profiling information from automated test tools, each stressing the same library or base code in different ways.
Merging results isn’t as much about getting high numerical precision on your bottlenecks. Sure, you can use it for numerical accuracy, but who cares if a routine takes 95% or 92.24638% of the CPU time? identifying the bottleneck is usually all that matters.
Merging is about figuring out the bottlenecks that matter in everyday use, bottlenecks which may not come up in your routine tests, or may not be seen as critical when seen in isolation. It can be about getting information on that odd, hard-to-reproduce, slowdown your users may be experiencing from time to time. It can also be about identifying the minor bottlenecks that could be the cause of a “sluggish” feel to your UI.
A last word on the SPR files: those are persistence streams of SamplingProfiler native format, they’re binary, highly compact, and for you, the user, highly proprietary and blackboxy. If you want to do your own analysis on the profiling results, there is an alternative: you can save results as an XML file, which will include all the data in a verbose fashion. Be warned however that a deceptively small SPR can result in a huge XML file.