-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cache demangling step #483
Comments
I am unsure about this one, to be honest. Yes, there could be some CPU gains to be had, but memory overhead is potentially close to unbounded. I haven't heard of anybody caching demangling results (though that doesn't have to mean much). Given that the demangling is basically the last step of symbolization, could you built that on top instead? I.e., instruct |
Agreed. Thanks for considering. Great library, simple APIs! |
Proposal for an extra line in the comment over the APIs
|
Good point. Will incorporate your suggestion. Thanks! |
Add a note to the Symbolizer type that it currently does not cache demangling results. Refs: libbpf#483
Add a note to the Symbolizer type that it currently does not cache demangling results. Refs: libbpf#483 Signed-off-by: Daniel Müller <deso@posteo.net>
Add a note to the Symbolizer type that it currently does not cache demangling results. Refs: #483 Signed-off-by: Daniel Müller <deso@posteo.net>
Thanks! Closing for now as the caching step is not essential. |
Context
The demangling step is done on the fly after retrieving the symbols from the cache.
This implies extra CPU costs when requesting demangled symbols.
Proposed solution
Add a demangled symbol entry within the caching structure.
The text was updated successfully, but these errors were encountered: