[PATCH] D115950: [llvm-profgen] Use shared string table for function name to save memory usage

Fri Dec 17 14:52:09 PST 2021

wlei added a comment.

In D115950#3200422 <https://reviews.llvm.org/D115950#3200422>, @hoy wrote:

> Thanks for the change. How much space do you see this helps save?

I just tested it on our search infra, surprisingly I didn't see any memory saved by this. I dived more and it showed that the FuncNameStrings is not a big consumer, only ~1GB compared to the total consumption (200GB+), that's petty small. Another guess is the library  have some optimization to allocate the string memory, but I'm not quite familiar with underlying optimization of string allocation.

================
Comment at: llvm/lib/MC/MCPseudoProbe.cpp:354

+    auto It = FuncNameStrings.insert(Name.str());
     // Initialize PseudoProbeFuncDesc and populate it into GUID2FuncDescMap
----------------
hoy wrote:
> wenlei wrote:
> > hoy wrote:
> > > wenlei wrote:
> > > > Just double checking, so the underlying data for probe section is freed after decoding? Where does that happen? 
> > > The real name is on the disk. When read, a temp object `ErrorOrName` is created which is then freed.
> > ErrorOrName doesn't own the underlying data. I was asking about the underlying data. The data is MCPseudoProbeDecoder::Data. Is OwningBinary taking care of the freeing?
> Yes, the binary object owns that underlying data buffer, i.e, pointed by `const uint8_t *Start`. 
> 
Yeah, the input binary info `OwningBinary<Binary> OBinary` is all freed after `load()` completed, otherwise we can directly use StringRef before.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D115950/new/

https://reviews.llvm.org/D115950