0

I recently used Mike Dunlavey's "Poor Man's Profiling" (How can I profile C++ code running on Linux? ) to find some surprising sources of overhead in my code. Yay.

To summarize, run your program in a debugger and manually capture some backtraces. If you find the same stack traces keep showing up, you have a pretty good idea of where the overheads are in your program.

The "identify" step requires eyeballing the stack traces. Humans are pretty good at pattern matching but I'd like to automate this process a bit.

Surely there is a tool that can take N backtraces and show me which backtraces were in which routines?

There is something called Stack Trace Analysis Tool (https://github.com/LLNL/STAT) but it operates on executables itself -- very much in the High Performance Computing domain where you might wonder why/where a parallel (MPI) program is hung. Not quite what I'm looking for: I have already collected the backtraces.

Rob Latham
  • 5,085
  • 3
  • 27
  • 44
  • What you need to know is *why* the program is spending time, not *where*. That requires an observer who understands the purpose of the program. No program can be such an observer (yet). By the way, it's "lavey", not "leavy" ;-) On a visit to Ireland I was told my name was misspelled. – Mike Dunlavey Feb 17 '22 at 12:45
  • Thanks for chiming in! fixed the name misspelling. To be clear I do intend to be the observer. I was just hoping for something to combine the common parts of the N stack traces (ten of ten start here in `main()`, ten of ten are in `process_stuff()` oh here's the difference: 5 of ten are in `allocate_data` while some are in `read_file()` and others are in `compute_splines()`. – Rob Latham Feb 17 '22 at 23:07
  • Tx. (I'm not immune from vanity :) OK, suppose on 30% of stacks `read_file` was on the stack. The line that's being called from tells you why, and the line that calls that. That tells you if that 30% is ***necessary***. Maybe it is, so look elsewhere. If it's something you can do without, you're looking to save about 30%, for a speedup of 1/(1-.3) or 43%. – Mike Dunlavey Feb 18 '22 at 00:42

0 Answers0