> The main disadvantage of tracing profilers implemented in this way is > that they introduce a fixed amount for every function call / line of code > execut

> The main disadvantage of tracing profilers implemented in this way is > that they introduce a fixed amount for every function call / line of code > executed. This can cause you to make incorrect decisions! For example, if > you have 2 implementations of something – one with a lot of function calls > and one without, which take the same amount of time, the one with a lot of > function calls will appear to be slower when profiled. I'm not convinced this is the main disadvantage of tracing profilers. The main disadvantage is that the perf impact tends to be much more severe. It's theoretically possible to mitigate the problem identified (keep track of how much time you spend profiling, and reduce the time tracked spent in the function by that amount). However, it's harder to have a tracing profiler which only profiles some functions, and harder to specify those. The nice thing about sampling profiles is that it's very easy to configure the performance impact and easy to get a good sample by just running for longer.