With the current getInliningInfoForAddress API, the FileName and FunctioName are both stored as std::string. This is not efficient for batch symbolization job as it incurs too much redundant string copy operation. This patch introduces a new API to allow user to specify customized inserter so that user can build a container that directly reference strings in the DWARF file to avoid string copy, which will speeds up batch symbolization by 2X.
Details
Diff Detail
- Build Status
Buildable 5729 Build 5729: arc lint + arc unit
Event Timeline
include/llvm/DebugInfo/DWARF/DWARFContext.h | ||
---|---|---|
205 | I'd expect to see changes to DIContext to add this as a virtual function there - and, say, changes to llvm-symbolizer to use this new API to exercise and benefit from the improvement? (& actually the old version could become non-virtual & implemented in DIContext so all clients don't have to implement both - that'd involve changing the COFF implementation to implement the std::function version too, which will help exercise/demonstrate that this API choice is generically beneficial to both formats, potentially) | |
207 | You can use llvm::function_ref here (it's like std::function, but doesn't have the overhead of separate allocation - used for when the functor doesn't need to be copied to outlive its scope) | |
207 | Is StringRef an option, rather than const char*? (especially if the length is already known due to previous string ops, perhaps) | |
207–208 | Might be worth using a struct rather than 8 arguments, for readability? | |
lib/DebugInfo/DWARF/DWARFContext.cpp | ||
560 | I'd probably rename this from "Inserter" (& probably update the comment) - it doesn't have to insert anything into anything. "Visitor", "Callback", "FrameHandler"? | |
lib/DebugInfo/DWARF/DWARFDebugLine.cpp | ||
707 | Pushing the use case through LLVM's symbolizer might also remove the need for keeping this function, maybe? Perhaps not. |
include/llvm/DebugInfo/DWARF/DWARFContext.h | ||
---|---|---|
208 | I'm not a fan of this type. Seems awfully easy to confuse the arguments. Since this function is only used in one place, do we even have to generalize it with std::function argument? |
I'd expect to see changes to DIContext to add this as a virtual function there - and, say, changes to llvm-symbolizer to use this new API to exercise and benefit from the improvement?
(& actually the old version could become non-virtual & implemented in DIContext so all clients don't have to implement both - that'd involve changing the COFF implementation to implement the std::function version too, which will help exercise/demonstrate that this API choice is generically beneficial to both formats, potentially)