Steinar Gunderson (who suggested [1] the talk-through-a-pipe approach) just now compared [2] the `libbfd` variant to the pipe-to-`addr2line` version, and found them to take similar amounts of time.
This agrees with what I saw in `top` while testing: with the patch, I see `perf` using ~95% CPU, with `addr2line` using the remaining ~5%.
So speeding up `addr2line` probably wouldn't result in very much of an overall improvement for this workload.
[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911815#28 [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911815#38
Re:60x speed-up of Linux “perf”
by vlovich123 on Thursday September 09, 2021 @11:07AM
(#28470501)
The piping is a good chunk of the gain but the gimli library is still much faster than addr2line & uses less memory if used correctly. Since libbfd shows similar results, I'm thinking there might be a speed bump from switching to use it (some care has to be taken to preserve 0-copy semantics across FFI).
It'd definitely be interesting to find out!
Looks interesting. I've encountered some annoying bugs with latest addr2line when trying to get symbols for addresses, wonder how gimli performs in that sense. Also, it seems that addr2line 2.37 has some performance regressions compared to 2.36.1 which I didn't look at yet.
Re:60x speed-up of Linux “perf”
by vlovich123 on Thursday September 09, 2021 @12:00PM
(#28471149)
In my experience gimli also symbolicated things addr2line couldn't.
I am curious about how that compares with libbfd since that wasn't under consideration for us as it uses GPLv3.
[1] https://github.com/gimli-rs/gimli
[2] https://github.com/gimli-rs/addr2line