jeremy-rifkin
commented
1 day ago Wow, 2GB of cache is huge. I haven't had to deal with anything of that magnitude yet and this may be something cpptrace isn't currently well-equipped to handle. Thanks for opening this issue.
I have a couple quick questions to help me understand your use-case better: Do you generate stack traces multiple times in a program? Do you need a trace generated reasonably quickly?
Is there any context you could provide about how big your application is? Do you happen to know if it utilizes many third-party libraries?
Some initial thoughts: Currently the caching isn't particularly smart, cpptrace just loads all relevant information from a translation unit. This is almost always fine, except for exceptionally large amounts of debug info. It should definitely be possible to implement something smarter. Attempting to load only relevant sections (and remember information needed to continue searches) could prove beneficial though DWARF doesn't make this as easy to do as I'd like. Something along the lines of a LRU cache might also be useful, though the use-case here is challenging as debug symbols are a hierarchical structure.
I will need to put together a test application for myself that's large enough to reproduce these issues, I'll have to look into that later.
xiewajueji
Problem: Some stacktrace is very large and it cost much memory in cache(about 2GB) and time to construct (about 4s). In our system, 2GB memory consume can not be adopted, because 4GB can be utilized.
Although there are 3 cache mode of cpptrace, but two of them except prioritize_speed can't shared lookup tables between trace calls which could slow the system and could(guess?) use more momory when two "large" stacktrace is constructing.
Is there a way that could both share lookup tables between trace and limit the total cache size? thx.