[HN Gopher] Profiling with Ctrl-C (2024)
___________________________________________________________________
Profiling with Ctrl-C (2024)
Author : hun3
Score : 72 points
Date : 2026-01-03 11:13 UTC (11 hours ago)
(HTM) web link (yosefk.com)
(TXT) w3m dump (yosefk.com)
| dzdt wrote:
| The first footnote here had me cackling aloud. Don't miss the
| footnotes!
| Brian_K_White wrote:
| 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.
| lelandfe wrote:
| "I stepped into a management role. Then I had to scrape it off
| my shoes."
| ahartmetz wrote:
| 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.
| vjvjvjvjghv wrote:
| 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.
| layer8 wrote:
| Luckily the article discusses that.
| silon42 wrote:
| 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).
| incanus77 wrote:
| 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.
| maccard wrote:
| > 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.
| eichin wrote:
| 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.
| tialaramex wrote:
| 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)
| nvartolomei wrote:
| Wrap gdb in a shell script and you've got yourself an actual
| profiler: https://poormansprofiler.org/
| baruch wrote:
| 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.
___________________________________________________________________
(page generated 2026-01-03 23:00 UTC)