41 ms·
As far as I can tell, there's not much of a reason to use an instrumenting profiler over a sampling one. Is there some niche use case? Maybe to experimentally v
by blt 9y ago
As far as I can tell, there's not much of a reason to use an instrumenting profiler over a sampling one. Is there some niche use case? Maybe to experimentally validate some claim about average case computational complexity?
- viraptor 9y agoCatching the runtime of a function that's executed very infrequently for example and has execution time extremely dependent on the context. (Which makes an isolated reproducer hard to achieve) Or finding out about a tiny function which is called thousands of times and adds up over time, but each execution is so fast you rarely ever see it on a sample profile.
- sciurus 9y agoIf that fast function is called enough to "add up", it should show up in the statistical profiler's samples. The likelihood of a function being sampled is influenced by the cumulative run time of all its calls, not the run time of an individual call.
- MaulingMonkey 9y ago> If that fast function is called enough to "add up", it should show up in the statistical profiler's samples. This can be messed with in a bunch of ways - aggressive inlining, being further subdivided because it's a template...
- sciurus 9y agoOh, sure, you may be right about that for other languages. I was thinking in the context of the post, which discusses Ruby and Python.
- hyperpape 9y agoI don't use tracing much because it produces such bad results, but I often find myself looking at a profile and thinking "I really wish I knew how many times this method was called".
- liuliu 9y agoWhen optimizing start up time for apps.
- trentnelson 9y ago> For long-running, batch-oriented programs, though, where there are no pathological corner cases, the usefulness of cProfile diminishes. It becomes hard to distinguish signal from noise with regards to the cumulative call counts and function time. Additionally, cProfile only captures function call entry and exit times -- it doesn't do line profiling, and thus, won't be able to depict abnormally expensive lines within a routine (this can be common with NumPy and Pandas; a seemingly innocuous line will actually have a very high overhead behind the scenes). From https://github.com/tpn/tracer https://github.com/tpn/tracer.
- MaulingMonkey 9y agoI use explicit instrumenting APIs to generate flamegraphs a lot - useful for a lot of niches in gamedev - where we care about individual frames exceeding their frame budget. Being able to capture several thousand frames worth of flame graphs and then being able to drill down into the individual outliers is absolutely killer in this context. Sampling profilers are great for getting a broad idea of where problems might be, but not nearly as good as instrumented options when you really want detail. For example: - Finding where we checked a file for modification on the main thread every few seconds, to consider reloading resources, causing us a 5ms spike that would sometimes cause us to miss vsync. - Spotting a framerate hitch caused by the main thread stalling out on a contested logging lock under some specific set of circumstances for a frame or two. - Spotting frames where overly aggressive background jobs simply starved the main thread out of CPU cycles. - Which specific subanimations of a set (complete with names because I'm using an explicit API that lets me annotate them) are causing our optimization code to exhibit O(scary) behavior. There's nothing here that you couldn't eventually figure out and solve with a debugger and a sampling profiler, but instrumenting profilers - and profiler APIs that let you add your own annotations - make the job way easier in my experience.
- blt 9y agoThis is a great answer, thanks!