dotTrace - what profiling settings should I use for my desktop app?

Question

When using dotTrace, I have to pick a profiling mode and a time measurement method. Profiling modes are:

• Tracing
• Line-by-line
• Sampling

And time measurement methods are:

• Wall time (performance counter)
• Thread time
• Wall time (CPU instruction)

Tracing and line-by-line can't use thread time measurement. But that still leaves me with seven different combinations to try. I've now read the dotTrace help pages on these well over a dozen times, and I remain no more knowledgeable than I started out about which one to pick.

I'm working on a WPF app that reads Word docs, extracts all the paragraphs and styles, and then loops through that extracted content to pick out document sections. I'm trying to optimize this process. (Currently it takes well over an hour to complete, so I'm trying to profile it for a given length of time rather than until it finishes.)

Which profiling and time measurement types would give me the best results? Or if the answer is "It depends", then what does it depend on? What are the pros and cons of a given profiling mode or time measurement method?

Answer 1

Profiling types:

• Sampling: fastest but least accurate profiling-type, minimum profiler overhead. Essentially equivalent to pausing the program many times a second and viewing the stacktrace; thus the number of calls per method is approximate. Still useful for identifying performance bottlenecks at the method-level.

  Snapshots captured in sampling mode occupy a lot less space on disk (I'd say 5-6 less space.) Use for initial assessment or when profiling a long-running application (which sounds like your case.)

• Tracing: Records the duration taken for each method. App under profiling runs slower but in return, dotTrace shows exact number of calls of each function, and function timing info is more accurate. This is good for diving into details of a problem at the method-level.

• Line-by-line: Profiles the program on a per-line basis. Largest resource hog but most fine-grained profiling results. Slows the program way down. The preferred tactic here is to initially profile using another type, and then hand-pick functions for line-by-line profiling.

---

As for meter kinds, I think they are described quite well in Getting started with dotTrace Performance by the great Hadi Hariri.

Wall time (CPU Instruction): This is the simplest and fastest way to measure wall time (that is, the time we observe on a wall clock). However, on some older multi-core processors this may produce incorrect results due to the cores timers being desynchronized. If this is the case, it is recommended to use Performance Counter.

Wall time (Performance Counter): Performance counters is part of the Windows API and it allows taking time samples in a hardware-independent way. However, being an API call, every measure takes substantial time and therefore has an impact on the profiled application.

Thread time: In a multi-threaded application concurrent threads contribute to each other's wall time. To avoid such interference we can use thread time meter which makes system API calls to get the amount of time given by the OS scheduler to the thread. The downsides are that taking thread time samples is much slower than using CPU counter and the precision is also limited by the size of quantum used by thread scheduler (normally 10ms). This mode is only supported when the Profiling Type is set to Sampling

However they don't differ too much.

---

I'm not a wizard in profiling myself but in your case I'd start with sampling to get a list of functions that take ridiculously long to execute, and then I'd mark them for line-by-line profiling.