Currently we have three maps all using function name std::string, a) FuncName in pseudo probe section(GUID2FuncDescMap) b) FuncName in debug info(BinaryFunctions) c) symbolizer (NameStrings). We can optimize to use one shared map and other two use StringRef to save memory usage.
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Time | Test | |
---|---|---|
60 ms | x64 debian > LLVM.Bindings/Go::go.test |
Event Timeline
llvm/lib/MC/MCPseudoProbe.cpp | ||
---|---|---|
354 | Just double checking, so the underlying data for probe section is freed after decoding? Where does that happen? |
Thanks for the change. How much space do you see this helps save?
llvm/lib/MC/MCPseudoProbe.cpp | ||
---|---|---|
354 | The real name is on the disk. When read, a temp object ErrorOrName is created which is then freed. |
llvm/lib/MC/MCPseudoProbe.cpp | ||
---|---|---|
354 | 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? |
llvm/lib/MC/MCPseudoProbe.cpp | ||
---|---|---|
354 | Yes, the binary object owns that underlying data buffer, i.e, pointed by const uint8_t *Start. |
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.
llvm/lib/MC/MCPseudoProbe.cpp | ||
---|---|---|
354 | Yeah, the input binary info OwningBinary<Binary> OBinary is all freed after load() completed, otherwise we can directly use StringRef before. |
Just double checking, so the underlying data for probe section is freed after decoding? Where does that happen?