Developing Programmers .com

First up, sorry I haven’t posted in a while. Developing Programmers has turned out not to be viable as a business option, so it has become instead a hobby. I will continue posting from time to time because I enjoy it, but less frequently and with less editing (because otherwise its too time-consuming to call “just a hobby”)

Today’s topic, profiling, is related to my past article about “optimising for simple“.

When you first write a program, don’t get too caught up in optimising for speed. If its optimised for simple, then it’ll be easy to re-arrange as you discover how your design works in practise.

Once this is done and you’re basically happy with a design, you might find its a bit slow. The thing to do at this point is run your program with a “profiler”.

A profiler is a tool that tells you where your program is spending its time. This is usually a breakdown by function, block and/or line of code.

This lets you do a sample run that includes the actions you’re concerned about, and find out where to spend your speed optimisation efforts. Often the “hot spots” that slow your program down aren’t where you would expect, so it’s really handy to be able to experiment and find out without bias where it really took its time.

Profilers usually have 2 stages:

Stage 1 is data collection. This involves instrumenting your program to record entry & exit times from subroutines, and usually a lot more information too. With profilers I have used, this has usually been a matter of running your program with special parameters or from inside another program, and getting your program to do whatever it is that’s slow.

Stage 2 is data analysis, which works out total and average time spent in each area of your program and creates a report. The details and presentation of the report varies a lot from one tool to another, but the basic information about where time was spent is pretty consistent.

You should find at least one profiler available for any common language, often more. My current project at work is in Perl so I recently used “NYTProf” to profile it. This particular profiler can generate HTML reports with color coding and explorable “click the function to see the lines in the function” detail, was very easy to use, and found for me in about 2 minutes a mistake I’d made that was seriously slowing down my code. This is the kind of thing that happens with profilers, and the reason you should explore which profilers are available for your language of the day.

At some point you get down to hotspots that are really necessary for your code to get the job done. That’s ok. The main thing is that its not wasting time.

As well as time spent in an area of your program, profilers generally show how often that part of the program was run. This can be invaluable in confirming whether something really matters (eg, perhaps it was a once-off startup cost and you’re not worried about startup time). It can also help with indicating code that would save you a lot of time if you can find a way to move it out of a loop.

A profiler will let you find the “easy wins” for speeding up your code, and can give insight into areas or approaches that are too slow. If you need speed, sometimes you will need to re-design part of your program to work differently, and it might feel like my advice about optimising for simple was for naught. It wasn’t.

First, this design-change situation is uncommon. The far more typical case is once you’ve fixed the “easy wins” your code will be “fast enough”.

Second, how did you know the design change was needed? By having something there to try out. Good thing it’s optimised for simple, so you have a working prototype that’s easy to change and experiment with. Imagine if you’d created complex code to optimise for speed and then found you were wrong about which approach to take?

So, following “optimise for simple” is “get to know your profiler”. Its a lot easier to make your code fast once you have concrete data about where its slow, and a lot easier to fix slowness if the design is simple.

Some starting points:

• For C/C++: Valgrind is both an excellent profiler and memory debugging tool. KCacheGrind can be a nice interface for parts of this functionality.
• For C/C++: GProf is also available although I haven’t tried it personally
• For Perl: NYTProf is made of awesome
• IDEs: Often these will come with (and perhaps even integrate with) profilers. In no particular order: xcode, visual studio, Eclipse.