LLVM time trace demangling resulted in a significant (10%?) compile time regression

[rnk]

In PR #87626 / 0fa20c5 LLVM began demangling function names when tracing optimization passes. Demangling C++ symbols can be really expensive, and on first glance, it seems we redo this work every time we remangle the same original symbol. There may be some opportunity to improve performance here:

• Can we memoize the names? Storing the demangled names once and keying them on Function* might speed things up, and it could also reduce memory usage, given that .symtab can often end up being a significant fraction of final object file size (20+%).
• Are we being lazy enough? Are we sure we are defering the work of demangling the name until after we've confirmed that we time trace scope passes the minimum time trace granularity?

CC @jamieschmeiser @Trass3r

[MaskRay]

I think we should store the raw symbol names in trace files. The symbol names have other use cases and I believe most profilers store the raw names as well. Users wanting demangled names could run c++filt/llvm-cxxfilt on the consumer side.

In the other words, I don't think the demangle in #87626 should be on by default.

[Trass3r]

@alecazam

[MaskRay]

/cherry-pick 72b73e2

[llvmbot]

/pull-request #102552

[alecazam]

I had to memoize them into a hashtable in my profiler. Then if not already in the table, then call demangle. So being able to avoid that in every tool processing the capture files would be ideal. Also this demangle is platform specific using macOS, and doesn't work with some Win symbols.

see demangleSymbolName
https://github.com/alecazam/kram/blob/main/kram-profile/Source/KramZipHelper.cpp