4 ms·
An amazing part of sampling-based profilers: They're so low overhead, you can leave them on permanently in production. And since all they're taking is counts, y
by ekimekim 9y ago
An amazing part of sampling-based profilers: They're so low overhead, you can leave them on permanently in production. And since all they're taking is counts, you can combine results from multiple instances very easily. Put this together and it forms an easy, highly insightful part of your production monitoring systems. Notice a service being slow? You can instantly see its live flamegraph, check a function's average runtime over time, etc.
- MuffinFlavored 9y agoCould you please share a really high level psuedo code example of what kind of data a sample-based profiler collects/how it does it?
- bgirard 9y agonew Thread('sampler') { run() { while (true) { samples.add(Thread.getAllStackTraces()); Thread.sleep(1ms); } } }.start(); Then you export all the stacks to a visualizer. The real java version of this is actually usable to find quick problems but will be inferior to real profilers because the 'getAllStackTraces' API wasn't designed for this. For C/C++ program you can use signals to implement the above. That's how the Firefox profiler works.
- amorphid 9y agoIn Ruby, check out https://apidock.com/ruby/Kernel/set_trace_func https://apidock.com/ruby/Kernel/set_trace_func. I believe Python has something similar, too.
- ekimekim 9y agoI'm referring to a sampling profiler - as mentioned in the article, these generally work on a timer (either a thread with a loop, or a recurring signal), not by a per-function callback.
- srean 9y agoIndeed. But careful there, if there is anything that's slowing down your system it can slow down the sampling tics as well and hide performance degradations. Its a good idea to record what's the time interval between tics. If tics are too frequent, this can again get you into trouble as this time interval computation can become relatively expensive.