This is an installment in a series covering the different components of a typical development environment. You may want to read Part 1, Part 2, Part 3, Part 4, Part 5, and perhaps especially Part 6 before reading this one, although it’s not strictly necessary.
Yesterday we covered the debugger, a dynamic code analysis tool which allows us to pinpoint certain unwanted behavior from our program in order to fix it. Today’s tool does something similar, but works in a specific kind of unwanted behavior.
Supposing a program’s output is correct, it doesn’t mean that the program is the best that it can be. Profilers analyze running software and help find the places at which most time is spent.
The time spent can be because of, principally, these reasons:
- Waiting for Input or Output operations to happen (read from disk, write to network, etc.)
- A certain piece of code gets called very often
- Cache misses
The last one is of special attention in many cases when our application isn’t running on its own or is running in a constrained environment. It happens because, literally, the data is stored relatively far from the processor. In the worst case scenario I’ve seen, the data has to be swapped from the hard disk drive.
The fact that much time is spent in a place doesn’t mean that it can be optimized, only that optimizations at those spots have a bigger impact on the overall performance.
The profiler is very similar to the debugger in terms of the information it needs to have about the analyzed binary and its goal. Thus, there are some programs which help do both profiling and debugging, like Valgrind.
A list of gratis profilers:
- JRockit Mission Control; works with JVM binaries
That’s it for Today. Next, we’ll see the Automated Build Tools, which is likely to be the second-to-last in this series.