Best way to measure speed of functions, classes and processes

Question

What is the best way to measure speed of functions and classes? For every function there are various solutions and I'd like to know how to measure running speed and optimize my shared classes with the best solution possible.

Also how do you measure SQL speed, for example differences between stored procedures, selects, views and etc.?

Answer 1

You have two options.

Use System.Diagnostics.Stopwatch for specific methods.

This is a high resolution timer in .NET which you can use for specific parts of your code.

Use a profiler if you need to measure performance for your entire application.

You can use the build in profiler of the Ultra edition of Visual Studio, or a tool like EQATEC.

Answer 2

You're best off using a profiler. The problem with measuring wallclock execution time (such as done by the Stopwatch class) is that it is influenced by many factors far out of your control. To mention just a few such factors, there's network and other I/O latency, and operating system scheduler decisions which influence the relative priority of applications and threads. If you are running inside a virtualized environment, that can also have a comparatively large effect on millisecond-range wallclock time measurements. The profiler won't be perfect, but it will give you a better idea of how much time is actually spent executing your code.

Besides that, a good profiler can often give you other useful metrics as well, like how much memory your code uses during execution.

Answer 3

It's best not to confuse the goals of measuring and optimizing. They are different tasks. Measuring, while good for quantifying the results of fixing something, is poor at telling you what to fix.

On the subject of measuring, if I want to make a presentation of how fast something is, I want a controlled environment and a good stopwatch. However, for the purpose of optimizing, crude measurements (like running something 1000 times) and using a simple timer, are more than good enough.

On the subject of optimizing, I am not concerned with speed. I am concerned with needless activity. It is not necessary to run the code at high speed to find it.

When any program runs, it traces out a call tree. Optimizing consists of removing as many leaves (instructions) and as much fruit (I/O) as possible. A good way to do this is to prune whole branches.

• In all but the smallest programs, the typical opportunities for optimization consist of call points (lines of code where functions are called, not the functions themselves) that, when one realizes how much of the call tree sprouts from them, could really be done another way. A single innocent-looking line of code could be responsible for a large fraction of the entire tree, and you might be able to simply chop it off.

To find those, I think wall-clock time stack sampling is the best way. It is not necessary for this to be an efficient process, and a rather small number of samples works just as well (or better) than a large number of samples. It is necessary to do it repeatedly, because any given program, as first written, doesn't contain just one opportunity for speedup. It contains several. Here's an example.