This is interestingly analogous to nelhage's memory sampling approach https://blog.nelhage.com/2013/03/tracking-an-eventmachine-le... where if something is leaking "at scale", let it - then gcore it, and pick a random page of the core and see what's there. (An even cheaper variant I've used a few times with python is to just run "strings | sort | uniq -c | sort -n" on the core, so you get the most common strings which are usually part of object metadata and give you a solid hint without needing to go in with a debugger...) The ^C approach basically samples time instead of memory.
> Which goes to show that Ctrl-C profiling is often enough to solve a simple problem, and it’s usually much easier than learning how to use a profiler and how to properly read its output
As the article says, this is a low frequency sampling profiler, which means it comes with all the caveats of a sampling profiler, and interpreting its output. As a very crude tool, sure, but it is not an excuse to not learnt to use a profiler. Perf, instruments and UIForETW are simple enough to use that anyone who can follow the instructions in this blog past can pick up the basics in the same length of time.
Sure, it's a fine technique if essentially one thing is consuming all the CPU time (and it shouldn't), which does happen. It becomes tedious when you're looking for the thing that consumes 20% or so of the CPU time.
Yes, this method is probably fine for finding the one big offender. But you quickly reach a point where you see 5% here and 5% there. Then you need a real profiler.
Once upon a time (maybe even before pthreads) I made an automatic version of this using SIGALARM for profiling.
I made a wrapper (using LD_PRELOAD) around XSelectInput that would trigger the signal 0.1 seconds after a keyboard/mouse (or other event) was received... Then it would dump stack traces every 0.1 seconds where "slow" UI code was being executed (before next call to XSelectInput).
Ages ago, working on an embedded system we did something similar by running gdb server on the embedded machine and gdb on the server and running a script to collect periodic stack traces to get a sampling profiler.
I kind of do a variant of this sometimes with “pause” in the Xcode debugger. If I’ve just encountered some kind of hang or delay, often hitting that will put me in the right place in the threads/call stack to figure out what I did.
The very similar "stepped in it" definitely has the same connotation in English.
But it needs the "it". "step in" alone or in any context where "it" isn't a mystery doesn't do it.
"step into the function" or "step into the hallway" doesn't do it even slightly.
The opposite even. In the case of "step into the hallway" where "step" does actually refer to literally using ones feet, saying step is a bit more sophisticated option for something like walk or go, invoking a sense of dancing vs merely relocating. So the "step in" is actually more elegant and tasteful.
Stepping into into or through a function doesn't invoke any dancing, merely the non-continuous, non-analog nature of the process.
But "here's where we stepped in it" has exactly the image and meaning he means.
Perhaps there is some other word in Russian that would do a better job of expressing something that proceeds in hard jumps? Maybe "step" was always just a too-literal translation from English or other languages because there is obviously a Russian word for "step"?
Is the 90-degree shape of stair called a step in Russian? Were instructions called steps in Russian before the western world put our own words for computer stuff into everyone else's languages overnight? Would a 400 year old document describe the recipe for a soup as a set of steps? In that case "step" was not merely a too-literal translation.
This is interestingly analogous to nelhage's memory sampling approach https://blog.nelhage.com/2013/03/tracking-an-eventmachine-le... where if something is leaking "at scale", let it - then gcore it, and pick a random page of the core and see what's there. (An even cheaper variant I've used a few times with python is to just run "strings | sort | uniq -c | sort -n" on the core, so you get the most common strings which are usually part of object metadata and give you a solid hint without needing to go in with a debugger...) The ^C approach basically samples time instead of memory.
Substantially pre-dated by e.g. Raymond Chen's explanation
https://devblogs.microsoft.com/oldnewthing/20050815-11/?p=34...
and by my implementation (for Linux) https://github.com/tialaramex/leakdice-rust or https://github.com/tialaramex/leakdice if you can't use Rust)
> Which goes to show that Ctrl-C profiling is often enough to solve a simple problem, and it’s usually much easier than learning how to use a profiler and how to properly read its output
As the article says, this is a low frequency sampling profiler, which means it comes with all the caveats of a sampling profiler, and interpreting its output. As a very crude tool, sure, but it is not an excuse to not learnt to use a profiler. Perf, instruments and UIForETW are simple enough to use that anyone who can follow the instructions in this blog past can pick up the basics in the same length of time.
Sure, it's a fine technique if essentially one thing is consuming all the CPU time (and it shouldn't), which does happen. It becomes tedious when you're looking for the thing that consumes 20% or so of the CPU time.
Yes, this method is probably fine for finding the one big offender. But you quickly reach a point where you see 5% here and 5% there. Then you need a real profiler.
Luckily the article discusses that.
Once upon a time (maybe even before pthreads) I made an automatic version of this using SIGALARM for profiling.
I made a wrapper (using LD_PRELOAD) around XSelectInput that would trigger the signal 0.1 seconds after a keyboard/mouse (or other event) was received... Then it would dump stack traces every 0.1 seconds where "slow" UI code was being executed (before next call to XSelectInput).
Ages ago, working on an embedded system we did something similar by running gdb server on the embedded machine and gdb on the server and running a script to collect periodic stack traces to get a sampling profiler.
I kind of do a variant of this sometimes with “pause” in the Xcode debugger. If I’ve just encountered some kind of hang or delay, often hitting that will put me in the right place in the threads/call stack to figure out what I did.
Wrap gdb in a shell script and you’ve got yourself an actual profiler: https://poormansprofiler.org/
The first footnote here had me cackling aloud. Don't miss the footnotes!
The very similar "stepped in it" definitely has the same connotation in English.
But it needs the "it". "step in" alone or in any context where "it" isn't a mystery doesn't do it.
"step into the function" or "step into the hallway" doesn't do it even slightly.
The opposite even. In the case of "step into the hallway" where "step" does actually refer to literally using ones feet, saying step is a bit more sophisticated option for something like walk or go, invoking a sense of dancing vs merely relocating. So the "step in" is actually more elegant and tasteful.
Stepping into into or through a function doesn't invoke any dancing, merely the non-continuous, non-analog nature of the process.
But "here's where we stepped in it" has exactly the image and meaning he means.
Perhaps there is some other word in Russian that would do a better job of expressing something that proceeds in hard jumps? Maybe "step" was always just a too-literal translation from English or other languages because there is obviously a Russian word for "step"?
Is the 90-degree shape of stair called a step in Russian? Were instructions called steps in Russian before the western world put our own words for computer stuff into everyone else's languages overnight? Would a 400 year old document describe the recipe for a soup as a set of steps? In that case "step" was not merely a too-literal translation.
"I stepped into a management role. Then I had to scrape it off my shoes."