16 ms·

60x speed-up of Linux “perf”

477 points by tonyg 5y ago

junon 5y ago
Yet another case of GPL virality causing more issues than it solves. E: Downvoters, have you read the article? The program started a new process for each address lookup instead of using a library because that library is GPL. Shall we have a discussion?
- AstralStorm 5y ago
  No. That is the case of Linus Torvalds not using the standard "or later" clause. He has his (bad) reasons. The incompatibility is caused by "lack of restrictions" clause. Without that, GPL becomes essentially BSD with all the corporate thievery that entails.
  - yakubin 5y ago
    The "or later" clause is a backdoor. Not wanting backdoors in your license doesn't seem like a bad reason to me.
    - globular-toast 5y ago
      So what's the solution? You can use a permissive licence which has a huge "backdoor" allowing derivatives to turn up under any licence, including GPLv3 (or v4). Or you can use GPLv2 with no "or later" clause which means you get situations like this.
      - yakubin 5y ago
        This incompatibility is a unique feature of GPL. Wherever it goes, it's incompatible with something (in this case, with itself). You could use MPL or CDDL and, as long as GPL isn't involved, you won't have problems with license compatibility. However, in the case of the Linux kernel (which "perf" is distributed with) changing the license is not an option --- no CLA and, even if it was practical to ask so many people for permission, many contributors are dead now. So here the only option is using dependencies which are compatible with GPLv2. So maybe we need a new library to replace libbfd, which would be more permissively licensed.
        globular-toast 5y ago
        It's not a feature of GPL, it's an unfortunate side-effect of copyleft. If you have a better way to "disable" copyright than copyleft then I'm sure it would supersede the GPL.
        josefx 5y ago
        > If you have a better way to "disable" copyright than copyleft then I'm sure it would supersede the GPL. In absence of copyright anyone could publish binaries build on GPL code without sharing the sources. So a central feature of the GPL would cease to be if copyright was in any way disabled. Saying the GPL is about disabling copyright is about as true as McDonalds being about healthy diets.
        yakubin 5y ago
        MPL and CDDL are copyleft licenses as well. It is a feature of GPL.
  - kaikki 5y ago
    What is a good source to get an understanding of all the Licenses and their relation?
    - spicybright 5y ago
      I've used this in the past. https://choosealicense.com/ https://choosealicense.com/
    - Someone 5y ago
      It isn’t easy, but these can help: - https://en.wikipedia.org/wiki/Comparison_of_free_and_open-source_software_licences https://en.wikipedia.org/wiki/Comparison_of_free_and_open-so... has a feature matrix for about 40 licenses - https://joinup.ec.europa.eu/collection/eupl/solution/joinup-licensing-assistant/jla-find-and-compare-software-licenses https://joinup.ec.europa.eu/collection/eupl/solution/joinup-... has a comprehensive set of features you might want a license to have, and shows matching licenses. You still would have to read up on what terms such as “trademark”, “copyright” or “copyleft” mean.
    - jcranmer 5y ago
      Here's a brief summary of major licenses: MIT, X11, BSD (2- or 3-clause), and more similar ones I can't name off the top of my head: these are the basic do-what-you-want license, the only requirements are things that every (good) license already has, such as standard limitation-of-warranty clauses and retention of copyright notice requirements. Apache (v2): This is the next stage up, which means that the text is lengthier and somewhat denser legalese, but also covers more topics such as trademarks and especially patents. The patent clause here includes a provision that any patent licenses are revoked if you sue the authors for patent infringement. MPL (v2): This is a weak copyleft requirement, which means that you must provide any changes to the source code when you distribute the binary and additionally the resultant code must be licensed under the same terms, although it only applies on a per-file basis. EPL, CDDL are broadly similar to the MPL, with a few differences in the legal minutiae. LGPL: Weak copyleft again, except now it's on a per-library basis. [Although, to be honest, the definition of per-library basis isn't entirely clear for non-C/C++ code.] GPL: Strong copyleft, which means that you pretty much have to use GPL if you reuse the code. AGPL: Even stronger than GPL, you have to distribute sources to anyone who uses your code over the network. With the GPL family, there's a distinction between version 2.1 and version 3 that retains relevance, because some people objected to the changes in GPLv3 (notably the anti-Tivoization clause and patent clause changes) and refused to move to GPLv3, with the Linux kernel being the most notable project to refuse to do so. As for relation, well, any license more complicated than Apache includes lots of legal minutiae that makes it somewhat hard to render judgement if two licenses are compatible or not. In general, though, you can usually use an earlier license in this list in a project that uses a later license, but usually only if both licenses are the latest version (as the most recent updates added some compatibility escape hatches).
  - kevincox 5y ago
    "or later" is a hack to get around the fact that the GPL is basically incompatible (I need a better word because this is overloaded) with itself if you change the name. If you want to use GPL and GPLRenamed libraries in the same project the only option is to relicence the project under both licences. This may be possible if you have few dependencies and few authors. But if you want to depend on a new library after some authors have become uncontactable you basically can't.
  - josteink 5y ago
    > That is the case of Linus Torvalds not using the standard "or later" clause. He has his (bad) reasons. Linus does not think GPLv3 is a good or fitting license for the Linux-kernel and that it changes too much things to be considered a new version of the same license as GPLv2. So he refuses to add the “or later” backdoor which would effectively relicense “his” kernel with a license he does not approve of. Is that not his right?
    - colejohnson66 5y ago
      It is, but we can still be petty about it.
  - jraph 5y ago
    Well, I don't think I agree with him and would licence GPL code with the "or later" clause, but he has a very reasonable and convincing argument against it. See this video of him explaining his take on GPLv3 and the "or later" clause at Deb Conf if you are interested: https://www.youtube.com/watch?v=PaKIZ7gJlRU https://www.youtube.com/watch?v=PaKIZ7gJlRU
- dvdkhlng 5y ago
  IMO it's not "GPL virality" that is at the root of the issue here. The authors' decision to license theis works this way causes the problem. You can still ask both libraries' authors for relicensing their work in a less restricted / more compatible way. If they don't want to do that, then being authors and owning their copyrights, that's their right to do. That's nothing I would blame on the GPL. I mean we should be grateful that these authors made their works available free of cost in the first place.
  - for1nner 5y ago
    > The authors' decision to license theis works this way causes the problem. I'm not sure how you can rationally make an argument for a framework that literally limits the use of improved or more performant code/technology/understanding simply because it does not share a philosophical view of IP/ownership/sharing. This is the core of the problem with IP in the real world as well, and I find it mind-boggling that we don't look at the SYSTEM and see it as problematic.
    - pessimizer 5y ago
      It doesn't limit it any more than if it were proprietary and you couldn't afford it.
    - aseipp 5y ago
      Actual IP law and how it conducts itself in the real world has plenty of issues to be sorted out, but there are tons of potential "inefficiencies" in the real world that could be exploited and rectified across a vast array of things, but aren't, due to combinations of social politics, law, philosophy, etc preventing it. That some potential efficiency is on the table in theory, but can't be reaped due to those things, is nowhere remotely close to "mind boggling"
  - nickitolas 5y ago
    As I understand it relicensing in many open source projects can be a very complicated matter, since in some cases it requires getting permission from all past contributors (Which could number in the hundreds)
- Spivak 5y ago
  It seems odd that the takeaway is "GPL sucks because it got in my way" and not "both authors' explicit wishes were respected." Assuming that this is in error and this isn't what the authors wanted to happen then it's fixable by someone changing their license.
  - ziml77 5y ago
    It's fixable with a license change, but in practice that's impossible for large projects. Without a CLA, every individual who's contributed is a copyright owner. If you can't get every single one of them to agree to change it, then the license is stuck. And it doesn't matter if the reason you can't get them to agree is because they've become uncontactable or died.
    - aaomidi 5y ago
      If they're dead then they're not going to stop you from changing the license. What are they gonna do? Sue you from beyond the grave?
      - faho 5y ago
        Inheritance exists.
      - CodeWriter23 5y ago
        Their heirs could do precisely that.
        colejohnson66 5y ago
        Yep. It’s how the Marvin Gaye lawsuits these past few years have been able to happen (despite him being dead). His estate is suing.
      - junon 5y ago
        IANAL but I believe a Qui Tam could take place by surviving family. Or inherited copyrights, etc.
- lnxg33k1 5y ago
  I guess MIT and Apache would be better, so that company can make billions on the code and contributors would still be poor (see AAPL -> FreeBSD)
  - NelsonMinar 5y ago
    You understand there's nothing in the GPL that prevents companies from making billions on the code without compensating the contributors?
    - lnxg33k1 5y ago
      The thing is with GPL you have to contribute back, see how much Linux has grown in functionalities and how backwards are other kernels with MIT --- You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange;
      - shrimp_emoji 5y ago
        But companies wouldn't use it anyway since it's GPL. Enter MPLv2, with the best of both worlds: - not viral copyleft - but users DO have to contribute back
        jabl 5y ago
        MPLv2 is a fine weak copyleft license, but I'm not really sure it prevents people from not contributing back if that's what they want: just put your proprietary code in a different file, add minimal API's to the MPL code so you can use it. So in that sense it's only very marginally 'better' than a fully permissive license.
- simion314 5y ago
  > more issues than it solves. Can you explain how you reach this conclusion? Assuming the GPL did not exist and the author would have made stuff proprietary, would that be better ? Some people like me would share code with GPL3 or later, why the f* should we give it to you as BSD? are you running on your devices only BSD code or MIT code ? or are you running proprietary software but for some reason making all stuff BSD will make your job easier since you could mindlesly copy paste shit in your proprietary stuff?
  - adwn 5y ago
    > Assuming the GPL did not exist and the author would have made stuff proprietary, would that be better ? That's a false dichotomy – there are many more open source licenses which wouldn't have led to the problem described in the article.
    - simion314 5y ago
      But respect the author decision, maybe the "problem" is what the author desired to happen.
- matheusmoreira 5y ago
  The root cause is copyright. If it were to be abolished, no one would ever have to think about licensing ever again. None of this pain would exist. Think about all the time that would be saved when people no longer need to think about all this lawyer bullshit.
  - junon 5y ago
    Not sure if this is a pisstake on my argument, but a world without copyright (or something similar) would be a world of endless exploitation and stifled innovation.
    - wizzwizz4 5y ago
      Copyright as it exists today does an awful lot of exploitation-enabling and innovation-stifling in itself. (And that's ignoring the rest of the IP suite.)
      - junon 5y ago
        This is like saying "cops today do a lot of nasty stuff, let's get rid of all cops". The result is pure, unmitigated anarchy, looting, murder, and lawlessness. I don't find either to be useful lines of thinking.
        matheusmoreira 5y ago
        Not really. Things would be pretty simple. You see something? You can copy it. Not a single legalese document in sight. Don't compare this stuff to police brutality, looting, murder. They're not even in the same realm. Intellectual property is just ideas and absurd notions of ownership. It's like trying to own numbers. The real brutality is sending people to jail over this.
    - matheusmoreira 5y ago
      > a world without copyright (or something similar) would be a world of endless exploitation and stifled innovation Says who? The copyright monopolists? There's plenty of historical evidence to the contrary: https://news.ycombinator.com/item?id=28330810 https://news.ycombinator.com/item?id=28330810 It seems obvious in hindsight. Less monopolies lead to more competition and better products. Even the US engaged in such infringement.
- bityard 5y ago
  With the "viral" name-calling you have already demonstrated that you don't want a rational discussion.
  - Dylan16807 5y ago
    No, using the normal term does not demonstrate that.
- tlamponi 5y ago
  > E: Downvoters, have you read the article? The program started a new process for each address lookup instead > of using a library because that library is GPL. > > Shall we have a discussion? Yeah no, they simply had a bad alternative implementation which could have been just as fast as the licence incompatible library call: > non-bfd, without patch: 7m59s > non-bfd, with patch: 15s > bfd: 15s -- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911815#38 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911815#38 The same could have happened due to other reasons for alternative implementation, that range from availability of more than one implementation with different advantages and disadvantages, different OS the code needs to run on, or simply preference. Blaming the license in this case is just short-sighted and with the wording used it just shows a bias of yours against the GPL, but not actual will to participate in a meaningful discussion on the linked thematic.
faho 5y ago
> Michał Sidor suggests building against libbfd, something that the Debian maintainers don’t want to do. "don't want to" isn't quite correct - they can't. Perf is licensed under the GPLv2, libbfd under the GPLv3. The licenses are incompatible, which makes the combination unredistributable - which is what Debian would be doing with it. Debian is legally not allowed to do this.
- AstralStorm 5y ago
  Unless perf has the standard clause allowing use of later versions of GPL. That would make it GPLv3 if linked against libbfd. Unfortunately it does not.
  - xxpor 5y ago
    That's pretty typical for things in the kernel ecosystem.
- compsciphd 5y ago
  its arguable when it comes to dynamic shared libraries (i.e. the ZFS argument).
- tonyg 5y ago
  You're right. I should clarify. Thank you!
- varajelle 5y ago
  Is there not an exception in the license for "system libraries" which libbfd kind of is?
  - faho 5y ago
    Is it? On my system the only things depending on binutils (which libbfd is part of) are gcc, clang and perf (seems archlinux doesn't care). That makes it arguably not a system library, so it's fair that Debian would want to steer clear of that interpretation.
deleted 5y ago
[deleted]
vlovich123 5y ago
I haven't blogged about this yet, but we saw a 1000x fold speed-up doing several things around symbolication. The more optimal approach we found was to use the gimli crate[1] directly & carefully optimize it to read in the data structures for the executable(s) you are symbolicating upfront & then issuing in-process queries. They also have a drop-in replacement of addr2line that outperforms it (both in symbolication speed & memory usage). 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 https://github.com/gimli-rs/gimli [2] https://github.com/gimli-rs/addr2line https://github.com/gimli-rs/addr2line
- tonyg 5y ago
  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 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911815#28 [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911815#38 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911815#38
  - vlovich123 5y ago
    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).
    - tonyg 5y ago
      It'd definitely be interesting to find out!
- vient 5y ago
tyingq 5y ago
Apparently llvm has a drop-in replacement for addr2line: https://llvm.org/docs/CommandGuide/llvm-addr2line.html https://llvm.org/docs/CommandGuide/llvm-addr2line.html I suppose you could make a library out of that.
nonbirithm 5y ago
It is a tough feeling to see someone else's design for a library that would be literally perfect for my needs, but I'm unable to use it because of the license, so I have to spend weeks implementing my own inferior version while carefully avoiding making the code too similar to what I happen to remember. I'm past believing that I'm smart enough to always be able to come up with/reimplement a competent enough solution for all my needs by myself every time. But copyright still has to be respected. When I'm forced into that situation from licensing issues, it really makes me feel like my skillset primarily revolves around gluing together other people's well-designed code, and being left to my own devices exposes my weakness in implementing something from scratch.
- adsche 5y ago
  Curious, what license(s) prevented you from using a library? Or maybe rather, what does "use" mean here?
  - nonbirithm 5y ago
    GPL, and in some cases source-available codebases produced by decompilation. "Use" in this case means to have some feature that's implemented by those libraries reimplemented in an open-source project (MIT-licensed).
  - ShrigmaMale 5y ago
    GPLv2, which is viral.
  - jeltz 5y ago
    GPL by some quite popular interpretations of what derivate work means. I do not personally agree but those interpretations are common enough to be a real concern and I do not think it has been tested in court yet (GPL has been tested in court but I do not think this particular aspect has).
- matheusmoreira 5y ago
  > carefully avoiding making the code too similar to what I happen to remember Is this really necessary? The GPL allows you to read and study the software. Is it really copyright infringement if you take your understanding and make your own program? Are people really forced to come up with convoluted new ways to solve the same problem just to avoid any similarity to existing work?
teleforce 5y ago
For those who're wondering what Linux perf can do, please check this excellent examples and descriptions: https://www.brendangregg.com/perf.html https://www.brendangregg.com/perf.html
deleted 5y ago
[deleted]
touisteur 5y ago
Oh no I hoped it was about speeding up perf record that is actually a big thorn on my side, one I wrote a specific tool for... Depending on the number of probes you use, perf record can induce large latency hits or reduced throughput. Batching/buffer disk writes solves the problem for me. But I had to redevelop a perf parser to record/compress smarter. And for network streaming (no touching the disk is even better...).
- tonyg 5y ago
  Sorry! :-) It was very much just scratching a particular itch I had related to cargo-flamegraph...
  - touisteur 5y ago
    Perf report is indeed slow AF, especially on large files, you're right in wanting to speed it up! Thanks for sharing! This is an interesting tidbit that has thrown me down a rabbit hole of 'profiling the profiler'...
- scottlamb 5y ago
  Neat! Is your tool open source? It'd be nice if perf record had a fundamentally faster way of working. I found a nice description of how it works in the README.md for cargo-trace: "perf relies on perf_event_open_sys to sample the stack. Every time a sample is taken, the entire stack is copied into user space. Stack unwinding is performed in user space as a post processing step. This wastes bandwidth and is a security concern as it may dump secrets like private keys." cargo-trace is apparently dormant now, but I found it really interesting. It does the unwinding via eBPF instead, which should be quicker while recording, not generate as much (sensitive) data, and not require as much post-processing. (Symbolization would still happen in post-processing.)
  - touisteur 5y ago
    I'll ask about opensourcing the tool. But just in case, the recipe is to use pipe mode and pre-parse all frames, stream them as messages, sometimes to several targets (pub/sub) with some streaming-zstd, and also splitting the pmu/probes/Intel-PT streams and treating them separately. Stack-traces are analysed (precomputed cfg optimised structure so unwinding is faster) before storing in adhoc in-house format with all other system traces. Only annoying thing is changing perf-record settings (pid changes, need event X, new probe) means restart and I ran out of interns before we had no-loss switchover...
saurik 5y ago
FINALLY AN ACTUAL ANSWER!! :D I had done a bunch of research into this a while ago and filed an issue with the Ubuntu bug tracker, but was told it was due to ABI stability (which did not make any sense). https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1894407 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1894407 Understanding that there is actually an underlying license problem is like finally being told all of the reasons for everything that happened on LOST ;P.
- mistrial9 5y ago
  > This bug affects 3 people (!)
  - fhaldridge7 5y ago
    I'm sure it affects more people than that. Not everyone who experiences this bug is going to create an account on the ubuntu launchpad platform and write a comment about it
  - andrepd 5y ago
    I'm absolutely positively sure that the amount of people using perf on Debian and derivatives (Ubuntu, Mint) is >>3
    - jhonsrid 5y ago
      Definitely, I always assumed perf was just super slow, (having only really used it in anger on debian). Glad the next time I get sucked down a performance tuning rabbit hole, I can make the process a lot less painful!
- rtpg 5y ago
  So `perf` is super slow on Ubuntu as well? I feel for distro maintainers, real thankless job trying to square the circle on a billion different things like this.
- thisisinterest 5y ago
  Perhaps you should add a link to this article as a comment in that ubuntu bug tracker. That way it's useful for others who have the same question.
halayli 5y ago
perf-report's slowness is very frustrating. This slowness started around 2017 or so. However, you can get around it by passing --no-inline and the graphs will be exactly the same.
unique_parrot2 5y ago
So all I am understanding is, we could make linux 10-100 times faster, but licensing-quirks don't allow it? Physical electricity, time and whatnot is wasted because of legal foo?
- foxfluff 5y ago
  No, you're not understanding it. Perf is a profiling tool. It's slow on Debian because reasons.
- danuker 5y ago
  The GPL requires that software linking to GPL projects are also licensed in GPL. This issue could be solved easily by releasing GPL software, that respects users' freedom.
  - Macha 5y ago
    Both packages involved here are GPL, but unfortunately have mutually exclusive version ranges (=2, and >=3)
londons_explore 5y ago
I would like to see a more general approach to solving the problem of "short lived processes are expensive". There needs to be a way to dynamically link a binary into your own address space, and call it's logic repeatedly, without incurring all the process startup overhead all the time. Pretty much, have all command line utilities be linkable like a library.
- xuhu 5y ago
  Afl-fuzz runs a program until main() and then forks it repeatedly. An empty main() can be called at least 10000 times per second this way.
  - xxpor 5y ago
    With AFL++ you can even determine exactly where the fork happens: https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/README.persistent_mode.md#3-deferred-initialization https://github.com/AFLplusplus/AFLplusplus/blob/stable/instr...
stabbles 5y ago
I wonder how many other packages suffer from this problem... Maybe building everything from sources isn't that bad after all.
a-dub 5y ago
is it the fork/exec overhead or the overhead of re-parsing the dwarf data that is responsible for the slowdown? process spawn thrash is obviously bad, but i'm curious how much it contributes to the issue here? forks are pretty cheap these days as i understand, and i think an exec may also be pretty cheap since the program image is already going to be sitting in the buffer cache. reading/parsing dwarf data, on the other hand, is likely to be slow. not totally sure, but maybe i/o could be sped up by mmap'ing in the dwarf data and maybe part of the parsing could be cached? fun story, i once solved a similar performance regression in a machine learning context, where calling code would serialize an entire model and pass it to inference code, which would then deserialize it all, make one inference, and then tear it all down. if online/streaming is not required, a huge speedup can come from just batching the work.
- tonyg 5y ago
  I suspect it's both. But I didn't measure, because the patch does away with both sources of overhead at the same time :-)
- glandium 5y ago
  Parsing the dwarf data has orders of magnitude more overhead than fork/exec. (source: I'm the one who opened the linked Debian bug)
dabreegster 5y ago
Does anybody have working instructions to build a patched perf for Ubuntu 20.04? I built from kernel.org following https://michcioperz.com/post/slow-perf-script/ https://michcioperz.com/post/slow-perf-script/, but somehow flamegraph pointed at the new build breaks totally -- after exiting the app, there's no "perf record: Woken up 181 times to write data" message; it just hangs.
- tonyg 5y ago
  Note that the patch does something other than what Michał's post ends up doing: instead of linking libbfd, it replaces lots of calls to addr2line with a single long-running call to addr2line. If you want to try the patch on Ubuntu, I recommend using the Debianish technique of "apt source linux-perf-5.10" (or whichever version of the kernel you're running) and applying the patch. Then "make" in the tools/perf directory, and it should work...
gnufx 5y ago
Silly rants about the GPL aside, why can't you use (LGPL) libelf, following its version of addr2line? The binutils-static rpm doc even says to use elfutils instead in new code -- no BFD? A quick look suggests RHEL's perf does so, but I'd need to check.
evmar 5y ago
In a separate context I discovered the slow performance of addr2line and wrote my own faster one as a learning experiment: http://neugierig.org/software/blog/2012/03/heap-profiling.html http://neugierig.org/software/blog/2012/03/heap-profiling.ht...
DSingularity 5y ago
Why not build from source and link against libbfd?
- tonyg 5y ago
  That would have solved my immediate problem, but the result is not distributable, so it wouldn't solve it generally, for others suffering the same thing.
tanjor 5y ago
I do know Boost.Stacktrace calls addr2line too. From the code(https://github.com/boostorg/stacktrace/blob/develop/include/boost/stacktrace/detail/addr2line_impls.hpp https://github.com/boostorg/stacktrace/blob/develop/include/...), it seems Boost.Stacktrace also shells out to addr2line for every address. But in practice, I found the overhead of boost::stacktrace::stacktrace() is not as horrendous as my crappy implementation, which calls addr2line, too. Is there something I missed in Boost's code?

477 points by tonyg 5y ago

Yet another case of GPL virality causing more issues than it solves. E: Downvoters, have you read the article? The program started a new process for each address lookup instead of using a library because that library is GPL. Shall we have a discussion?

AstralStorm 5y ago
No. That is the case of Linus Torvalds not using the standard "or later" clause. He has his (bad) reasons. The incompatibility is caused by "lack of restrictions" clause. Without that, GPL becomes essentially BSD with all the corporate thievery that entails.
- yakubin 5y ago
  The "or later" clause is a backdoor. Not wanting backdoors in your license doesn't seem like a bad reason to me.
  - globular-toast 5y ago
    So what's the solution? You can use a permissive licence which has a huge "backdoor" allowing derivatives to turn up under any licence, including GPLv3 (or v4). Or you can use GPLv2 with no "or later" clause which means you get situations like this.
    - yakubin 5y ago
      This incompatibility is a unique feature of GPL. Wherever it goes, it's incompatible with something (in this case, with itself). You could use MPL or CDDL and, as long as GPL isn't involved, you won't have problems with license compatibility. However, in the case of the Linux kernel (which "perf" is distributed with) changing the license is not an option --- no CLA and, even if it was practical to ask so many people for permission, many contributors are dead now. So here the only option is using dependencies which are compatible with GPLv2. So maybe we need a new library to replace libbfd, which would be more permissively licensed.
      - globular-toast 5y ago
        It's not a feature of GPL, it's an unfortunate side-effect of copyleft. If you have a better way to "disable" copyright than copyleft then I'm sure it would supersede the GPL.
        josefx 5y ago
        > If you have a better way to "disable" copyright than copyleft then I'm sure it would supersede the GPL. In absence of copyright anyone could publish binaries build on GPL code without sharing the sources. So a central feature of the GPL would cease to be if copyright was in any way disabled. Saying the GPL is about disabling copyright is about as true as McDonalds being about healthy diets.
        yakubin 5y ago
        MPL and CDDL are copyleft licenses as well. It is a feature of GPL.
- kaikki 5y ago
  What is a good source to get an understanding of all the Licenses and their relation?
  - spicybright 5y ago
    I've used this in the past. https://choosealicense.com/ https://choosealicense.com/
  - Someone 5y ago
    It isn’t easy, but these can help: - https://en.wikipedia.org/wiki/Comparison_of_free_and_open-source_software_licences https://en.wikipedia.org/wiki/Comparison_of_free_and_open-so... has a feature matrix for about 40 licenses - https://joinup.ec.europa.eu/collection/eupl/solution/joinup-licensing-assistant/jla-find-and-compare-software-licenses https://joinup.ec.europa.eu/collection/eupl/solution/joinup-... has a comprehensive set of features you might want a license to have, and shows matching licenses. You still would have to read up on what terms such as “trademark”, “copyright” or “copyleft” mean.
  - jcranmer 5y ago
    Here's a brief summary of major licenses: MIT, X11, BSD (2- or 3-clause), and more similar ones I can't name off the top of my head: these are the basic do-what-you-want license, the only requirements are things that every (good) license already has, such as standard limitation-of-warranty clauses and retention of copyright notice requirements. Apache (v2): This is the next stage up, which means that the text is lengthier and somewhat denser legalese, but also covers more topics such as trademarks and especially patents. The patent clause here includes a provision that any patent licenses are revoked if you sue the authors for patent infringement. MPL (v2): This is a weak copyleft requirement, which means that you must provide any changes to the source code when you distribute the binary and additionally the resultant code must be licensed under the same terms, although it only applies on a per-file basis. EPL, CDDL are broadly similar to the MPL, with a few differences in the legal minutiae. LGPL: Weak copyleft again, except now it's on a per-library basis. [Although, to be honest, the definition of per-library basis isn't entirely clear for non-C/C++ code.] GPL: Strong copyleft, which means that you pretty much have to use GPL if you reuse the code. AGPL: Even stronger than GPL, you have to distribute sources to anyone who uses your code over the network. With the GPL family, there's a distinction between version 2.1 and version 3 that retains relevance, because some people objected to the changes in GPLv3 (notably the anti-Tivoization clause and patent clause changes) and refused to move to GPLv3, with the Linux kernel being the most notable project to refuse to do so. As for relation, well, any license more complicated than Apache includes lots of legal minutiae that makes it somewhat hard to render judgement if two licenses are compatible or not. In general, though, you can usually use an earlier license in this list in a project that uses a later license, but usually only if both licenses are the latest version (as the most recent updates added some compatibility escape hatches).
- kevincox 5y ago
  "or later" is a hack to get around the fact that the GPL is basically incompatible (I need a better word because this is overloaded) with itself if you change the name. If you want to use GPL and GPLRenamed libraries in the same project the only option is to relicence the project under both licences. This may be possible if you have few dependencies and few authors. But if you want to depend on a new library after some authors have become uncontactable you basically can't.
- josteink 5y ago
  > That is the case of Linus Torvalds not using the standard "or later" clause. He has his (bad) reasons. Linus does not think GPLv3 is a good or fitting license for the Linux-kernel and that it changes too much things to be considered a new version of the same license as GPLv2. So he refuses to add the “or later” backdoor which would effectively relicense “his” kernel with a license he does not approve of. Is that not his right?
  - colejohnson66 5y ago
    It is, but we can still be petty about it.
- jraph 5y ago
  Well, I don't think I agree with him and would licence GPL code with the "or later" clause, but he has a very reasonable and convincing argument against it. See this video of him explaining his take on GPLv3 and the "or later" clause at Deb Conf if you are interested: https://www.youtube.com/watch?v=PaKIZ7gJlRU https://www.youtube.com/watch?v=PaKIZ7gJlRU
dvdkhlng 5y ago
IMO it's not "GPL virality" that is at the root of the issue here. The authors' decision to license theis works this way causes the problem. You can still ask both libraries' authors for relicensing their work in a less restricted / more compatible way. If they don't want to do that, then being authors and owning their copyrights, that's their right to do. That's nothing I would blame on the GPL. I mean we should be grateful that these authors made their works available free of cost in the first place.
- for1nner 5y ago
  > The authors' decision to license theis works this way causes the problem. I'm not sure how you can rationally make an argument for a framework that literally limits the use of improved or more performant code/technology/understanding simply because it does not share a philosophical view of IP/ownership/sharing. This is the core of the problem with IP in the real world as well, and I find it mind-boggling that we don't look at the SYSTEM and see it as problematic.
  - pessimizer 5y ago
    It doesn't limit it any more than if it were proprietary and you couldn't afford it.
  - aseipp 5y ago
    Actual IP law and how it conducts itself in the real world has plenty of issues to be sorted out, but there are tons of potential "inefficiencies" in the real world that could be exploited and rectified across a vast array of things, but aren't, due to combinations of social politics, law, philosophy, etc preventing it. That some potential efficiency is on the table in theory, but can't be reaped due to those things, is nowhere remotely close to "mind boggling"
- nickitolas 5y ago
  As I understand it relicensing in many open source projects can be a very complicated matter, since in some cases it requires getting permission from all past contributors (Which could number in the hundreds)
Spivak 5y ago
It seems odd that the takeaway is "GPL sucks because it got in my way" and not "both authors' explicit wishes were respected." Assuming that this is in error and this isn't what the authors wanted to happen then it's fixable by someone changing their license.
- ziml77 5y ago
  It's fixable with a license change, but in practice that's impossible for large projects. Without a CLA, every individual who's contributed is a copyright owner. If you can't get every single one of them to agree to change it, then the license is stuck. And it doesn't matter if the reason you can't get them to agree is because they've become uncontactable or died.
  - aaomidi 5y ago
    If they're dead then they're not going to stop you from changing the license. What are they gonna do? Sue you from beyond the grave?
    - faho 5y ago
      Inheritance exists.
    - CodeWriter23 5y ago
      Their heirs could do precisely that.
      - colejohnson66 5y ago
        Yep. It’s how the Marvin Gaye lawsuits these past few years have been able to happen (despite him being dead). His estate is suing.
    - junon 5y ago
      IANAL but I believe a Qui Tam could take place by surviving family. Or inherited copyrights, etc.
lnxg33k1 5y ago
I guess MIT and Apache would be better, so that company can make billions on the code and contributors would still be poor (see AAPL -> FreeBSD)
- NelsonMinar 5y ago
  You understand there's nothing in the GPL that prevents companies from making billions on the code without compensating the contributors?
  - lnxg33k1 5y ago
    The thing is with GPL you have to contribute back, see how much Linux has grown in functionalities and how backwards are other kernels with MIT --- You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange;
    - shrimp_emoji 5y ago
      But companies wouldn't use it anyway since it's GPL. Enter MPLv2, with the best of both worlds: - not viral copyleft - but users DO have to contribute back
      - jabl 5y ago
        MPLv2 is a fine weak copyleft license, but I'm not really sure it prevents people from not contributing back if that's what they want: just put your proprietary code in a different file, add minimal API's to the MPL code so you can use it. So in that sense it's only very marginally 'better' than a fully permissive license.
simion314 5y ago
> more issues than it solves. Can you explain how you reach this conclusion? Assuming the GPL did not exist and the author would have made stuff proprietary, would that be better ? Some people like me would share code with GPL3 or later, why the f* should we give it to you as BSD? are you running on your devices only BSD code or MIT code ? or are you running proprietary software but for some reason making all stuff BSD will make your job easier since you could mindlesly copy paste shit in your proprietary stuff?
- adwn 5y ago
  > Assuming the GPL did not exist and the author would have made stuff proprietary, would that be better ? That's a false dichotomy – there are many more open source licenses which wouldn't have led to the problem described in the article.
  - simion314 5y ago
    But respect the author decision, maybe the "problem" is what the author desired to happen.
matheusmoreira 5y ago
The root cause is copyright. If it were to be abolished, no one would ever have to think about licensing ever again. None of this pain would exist. Think about all the time that would be saved when people no longer need to think about all this lawyer bullshit.
- junon 5y ago
  Not sure if this is a pisstake on my argument, but a world without copyright (or something similar) would be a world of endless exploitation and stifled innovation.
  - wizzwizz4 5y ago
    Copyright as it exists today does an awful lot of exploitation-enabling and innovation-stifling in itself. (And that's ignoring the rest of the IP suite.)
    - junon 5y ago
      This is like saying "cops today do a lot of nasty stuff, let's get rid of all cops". The result is pure, unmitigated anarchy, looting, murder, and lawlessness. I don't find either to be useful lines of thinking.
      - matheusmoreira 5y ago
        Not really. Things would be pretty simple. You see something? You can copy it. Not a single legalese document in sight. Don't compare this stuff to police brutality, looting, murder. They're not even in the same realm. Intellectual property is just ideas and absurd notions of ownership. It's like trying to own numbers. The real brutality is sending people to jail over this.
  - matheusmoreira 5y ago
    > a world without copyright (or something similar) would be a world of endless exploitation and stifled innovation Says who? The copyright monopolists? There's plenty of historical evidence to the contrary: https://news.ycombinator.com/item?id=28330810 https://news.ycombinator.com/item?id=28330810 It seems obvious in hindsight. Less monopolies lead to more competition and better products. Even the US engaged in such infringement.
bityard 5y ago
With the "viral" name-calling you have already demonstrated that you don't want a rational discussion.
- Dylan16807 5y ago
  No, using the normal term does not demonstrate that.
tlamponi 5y ago
> E: Downvoters, have you read the article? The program started a new process for each address lookup instead > of using a library because that library is GPL. > > Shall we have a discussion? Yeah no, they simply had a bad alternative implementation which could have been just as fast as the licence incompatible library call: > non-bfd, without patch: 7m59s > non-bfd, with patch: 15s > bfd: 15s -- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911815#38 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911815#38 The same could have happened due to other reasons for alternative implementation, that range from availability of more than one implementation with different advantages and disadvantages, different OS the code needs to run on, or simply preference. Blaming the license in this case is just short-sighted and with the wording used it just shows a bias of yours against the GPL, but not actual will to participate in a meaningful discussion on the linked thematic.

faho 5y ago

> Michał Sidor suggests building against libbfd, something that the Debian maintainers don’t want to do. "don't want to" isn't quite correct - they can't. Perf is licensed under the GPLv2, libbfd under the GPLv3. The licenses are incompatible, which makes the combination unredistributable - which is what Debian would be doing with it. Debian is legally not allowed to do this.

AstralStorm 5y ago
Unless perf has the standard clause allowing use of later versions of GPL. That would make it GPLv3 if linked against libbfd. Unfortunately it does not.
- xxpor 5y ago
  That's pretty typical for things in the kernel ecosystem.
compsciphd 5y ago
its arguable when it comes to dynamic shared libraries (i.e. the ZFS argument).
tonyg 5y ago
You're right. I should clarify. Thank you!
varajelle 5y ago
Is there not an exception in the license for "system libraries" which libbfd kind of is?
- faho 5y ago
  Is it? On my system the only things depending on binutils (which libbfd is part of) are gcc, clang and perf (seems archlinux doesn't care). That makes it arguably not a system library, so it's fair that Debian would want to steer clear of that interpretation.

deleted 5y ago

[deleted]

vlovich123 5y ago

I haven't blogged about this yet, but we saw a 1000x fold speed-up doing several things around symbolication. The more optimal approach we found was to use the gimli crate[1] directly & carefully optimize it to read in the data structures for the executable(s) you are symbolicating upfront & then issuing in-process queries. They also have a drop-in replacement of addr2line that outperforms it (both in symbolication speed & memory usage). 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 https://github.com/gimli-rs/gimli [2] https://github.com/gimli-rs/addr2line https://github.com/gimli-rs/addr2line

tonyg 5y ago
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 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911815#28 [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911815#38 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911815#38
- vlovich123 5y ago
  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).
  - tonyg 5y ago
    It'd definitely be interesting to find out!
vient 5y ago

tyingq 5y ago

Apparently llvm has a drop-in replacement for addr2line: https://llvm.org/docs/CommandGuide/llvm-addr2line.html https://llvm.org/docs/CommandGuide/llvm-addr2line.html I suppose you could make a library out of that.

nonbirithm 5y ago

It is a tough feeling to see someone else's design for a library that would be literally perfect for my needs, but I'm unable to use it because of the license, so I have to spend weeks implementing my own inferior version while carefully avoiding making the code too similar to what I happen to remember. I'm past believing that I'm smart enough to always be able to come up with/reimplement a competent enough solution for all my needs by myself every time. But copyright still has to be respected. When I'm forced into that situation from licensing issues, it really makes me feel like my skillset primarily revolves around gluing together other people's well-designed code, and being left to my own devices exposes my weakness in implementing something from scratch.

adsche 5y ago
Curious, what license(s) prevented you from using a library? Or maybe rather, what does "use" mean here?
- nonbirithm 5y ago
  GPL, and in some cases source-available codebases produced by decompilation. "Use" in this case means to have some feature that's implemented by those libraries reimplemented in an open-source project (MIT-licensed).
- ShrigmaMale 5y ago
  GPLv2, which is viral.
- jeltz 5y ago
  GPL by some quite popular interpretations of what derivate work means. I do not personally agree but those interpretations are common enough to be a real concern and I do not think it has been tested in court yet (GPL has been tested in court but I do not think this particular aspect has).
matheusmoreira 5y ago
> carefully avoiding making the code too similar to what I happen to remember Is this really necessary? The GPL allows you to read and study the software. Is it really copyright infringement if you take your understanding and make your own program? Are people really forced to come up with convoluted new ways to solve the same problem just to avoid any similarity to existing work?

teleforce 5y ago

For those who're wondering what Linux perf can do, please check this excellent examples and descriptions: https://www.brendangregg.com/perf.html https://www.brendangregg.com/perf.html

deleted 5y ago

[deleted]

touisteur 5y ago

Oh no I hoped it was about speeding up perf record that is actually a big thorn on my side, one I wrote a specific tool for... Depending on the number of probes you use, perf record can induce large latency hits or reduced throughput. Batching/buffer disk writes solves the problem for me. But I had to redevelop a perf parser to record/compress smarter. And for network streaming (no touching the disk is even better...).

tonyg 5y ago
Sorry! :-) It was very much just scratching a particular itch I had related to cargo-flamegraph...
- touisteur 5y ago
  Perf report is indeed slow AF, especially on large files, you're right in wanting to speed it up! Thanks for sharing! This is an interesting tidbit that has thrown me down a rabbit hole of 'profiling the profiler'...
scottlamb 5y ago
Neat! Is your tool open source? It'd be nice if perf record had a fundamentally faster way of working. I found a nice description of how it works in the README.md for cargo-trace: "perf relies on perf_event_open_sys to sample the stack. Every time a sample is taken, the entire stack is copied into user space. Stack unwinding is performed in user space as a post processing step. This wastes bandwidth and is a security concern as it may dump secrets like private keys." cargo-trace is apparently dormant now, but I found it really interesting. It does the unwinding via eBPF instead, which should be quicker while recording, not generate as much (sensitive) data, and not require as much post-processing. (Symbolization would still happen in post-processing.)
- touisteur 5y ago
  I'll ask about opensourcing the tool. But just in case, the recipe is to use pipe mode and pre-parse all frames, stream them as messages, sometimes to several targets (pub/sub) with some streaming-zstd, and also splitting the pmu/probes/Intel-PT streams and treating them separately. Stack-traces are analysed (precomputed cfg optimised structure so unwinding is faster) before storing in adhoc in-house format with all other system traces. Only annoying thing is changing perf-record settings (pid changes, need event X, new probe) means restart and I ran out of interns before we had no-loss switchover...

saurik 5y ago

FINALLY AN ACTUAL ANSWER!! :D I had done a bunch of research into this a while ago and filed an issue with the Ubuntu bug tracker, but was told it was due to ABI stability (which did not make any sense). https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1894407 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1894407 Understanding that there is actually an underlying license problem is like finally being told all of the reasons for everything that happened on LOST ;P.

mistrial9 5y ago
> This bug affects 3 people (!)
- fhaldridge7 5y ago
  I'm sure it affects more people than that. Not everyone who experiences this bug is going to create an account on the ubuntu launchpad platform and write a comment about it
- andrepd 5y ago
  I'm absolutely positively sure that the amount of people using perf on Debian and derivatives (Ubuntu, Mint) is >>3
  - jhonsrid 5y ago
    Definitely, I always assumed perf was just super slow, (having only really used it in anger on debian). Glad the next time I get sucked down a performance tuning rabbit hole, I can make the process a lot less painful!
rtpg 5y ago
So `perf` is super slow on Ubuntu as well? I feel for distro maintainers, real thankless job trying to square the circle on a billion different things like this.
thisisinterest 5y ago
Perhaps you should add a link to this article as a comment in that ubuntu bug tracker. That way it's useful for others who have the same question.

halayli 5y ago

perf-report's slowness is very frustrating. This slowness started around 2017 or so. However, you can get around it by passing --no-inline and the graphs will be exactly the same.

unique_parrot2 5y ago

So all I am understanding is, we could make linux 10-100 times faster, but licensing-quirks don't allow it? Physical electricity, time and whatnot is wasted because of legal foo?

foxfluff 5y ago
No, you're not understanding it. Perf is a profiling tool. It's slow on Debian because reasons.
danuker 5y ago
The GPL requires that software linking to GPL projects are also licensed in GPL. This issue could be solved easily by releasing GPL software, that respects users' freedom.
- Macha 5y ago
  Both packages involved here are GPL, but unfortunately have mutually exclusive version ranges (=2, and >=3)

londons_explore 5y ago

I would like to see a more general approach to solving the problem of "short lived processes are expensive". There needs to be a way to dynamically link a binary into your own address space, and call it's logic repeatedly, without incurring all the process startup overhead all the time. Pretty much, have all command line utilities be linkable like a library.

xuhu 5y ago
Afl-fuzz runs a program until main() and then forks it repeatedly. An empty main() can be called at least 10000 times per second this way.
- xxpor 5y ago
  With AFL++ you can even determine exactly where the fork happens: https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/README.persistent_mode.md#3-deferred-initialization https://github.com/AFLplusplus/AFLplusplus/blob/stable/instr...

stabbles 5y ago

I wonder how many other packages suffer from this problem... Maybe building everything from sources isn't that bad after all.

a-dub 5y ago

is it the fork/exec overhead or the overhead of re-parsing the dwarf data that is responsible for the slowdown? process spawn thrash is obviously bad, but i'm curious how much it contributes to the issue here? forks are pretty cheap these days as i understand, and i think an exec may also be pretty cheap since the program image is already going to be sitting in the buffer cache. reading/parsing dwarf data, on the other hand, is likely to be slow. not totally sure, but maybe i/o could be sped up by mmap'ing in the dwarf data and maybe part of the parsing could be cached? fun story, i once solved a similar performance regression in a machine learning context, where calling code would serialize an entire model and pass it to inference code, which would then deserialize it all, make one inference, and then tear it all down. if online/streaming is not required, a huge speedup can come from just batching the work.

tonyg 5y ago
I suspect it's both. But I didn't measure, because the patch does away with both sources of overhead at the same time :-)
glandium 5y ago
Parsing the dwarf data has orders of magnitude more overhead than fork/exec. (source: I'm the one who opened the linked Debian bug)

dabreegster 5y ago

Does anybody have working instructions to build a patched perf for Ubuntu 20.04? I built from kernel.org following https://michcioperz.com/post/slow-perf-script/ https://michcioperz.com/post/slow-perf-script/, but somehow flamegraph pointed at the new build breaks totally -- after exiting the app, there's no "perf record: Woken up 181 times to write data" message; it just hangs.

tonyg 5y ago
Note that the patch does something other than what Michał's post ends up doing: instead of linking libbfd, it replaces lots of calls to addr2line with a single long-running call to addr2line. If you want to try the patch on Ubuntu, I recommend using the Debianish technique of "apt source linux-perf-5.10" (or whichever version of the kernel you're running) and applying the patch. Then "make" in the tools/perf directory, and it should work...

gnufx 5y ago

Silly rants about the GPL aside, why can't you use (LGPL) libelf, following its version of addr2line? The binutils-static rpm doc even says to use elfutils instead in new code -- no BFD? A quick look suggests RHEL's perf does so, but I'd need to check.

evmar 5y ago

In a separate context I discovered the slow performance of addr2line and wrote my own faster one as a learning experiment: http://neugierig.org/software/blog/2012/03/heap-profiling.html http://neugierig.org/software/blog/2012/03/heap-profiling.ht...

DSingularity 5y ago

Why not build from source and link against libbfd?

tonyg 5y ago
That would have solved my immediate problem, but the result is not distributable, so it wouldn't solve it generally, for others suffering the same thing.

tanjor 5y ago

I do know Boost.Stacktrace calls addr2line too. From the code(https://github.com/boostorg/stacktrace/blob/develop/include/boost/stacktrace/detail/addr2line_impls.hpp https://github.com/boostorg/stacktrace/blob/develop/include/...), it seems Boost.Stacktrace also shells out to addr2line for every address. But in practice, I found the overhead of boost::stacktrace::stacktrace() is not as horrendous as my crappy implementation, which calls addr2line, too. Is there something I missed in Boost's code?