Code Optimization: Go For the Jugular

Code optimization can sometimes be experienced as a lengthy process, with disruptive effects on code readability and maintainability. For effective optimization, it is crucial to focus efforts on areas where minimal work and minimal changes will have to most impact, ie. go for the jugular


begin…end as bottlenecks?

There will come a time when SamplingProfiler may report you that begin or end are your bottlenecks. This may sound a little surprising, but it’s actually quite a common occurrence, and something that instrumenting profilers are not going to point out, so it might be worth a little explanation.


Website getting up to speed

I’ve reorganized the site a bit since the relocation, tweaked WordPress behind the scenes, added OpenID support for comments and hopefully sorted out the over-aggressive spam filter.

The support forums are no longer available now also hosted here, no OpenID support for them just yet, but I’ll enable it as soon as it’s out of beta. For bug reports and features/suggestions, the forums are the place to post (easier to track things).

There will likely be a new SamplingProfiler release in the next days, which will add support for CPU-usage-based sampling, ie. profiling only takes place when the CPU usage goes above above a treshold (either at the system or the process level).

Saving results & merging

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.