https://github.com/JDevlieghere requested changes to this pull request.
Agreed that using the offset and the byte size to encode a string pointer is a recipe for disaster. That said, out of all the objects in LLDB, `Symbol` is probably one of the most, if not the most, important to keep as small as possible. Given we have so many instances, I think it's worthwhile to optimize. In its current state, this PR increases the `Symbol` size by more than two pointers. `ConstString` is 8 bytes, but `FileSpec` holds another two (16 bytes), plus some metadata (let's say 8 bytes). That's an additional 32 bytes per `Symbol`. Can we store a unique pointer to a struct that holds these fields? That way only symbols of type `eSymbolTypeReExported` pay the additional cost (and a little extra for the indirection), while all the other symbols (which I'm assuming is the vast majority) only grow 8 bytes. I also think it would be worthwhile to compare the memory usage of lldb before and after the patch with something representative like the clang binary. https://github.com/llvm/llvm-project/pull/172565 _______________________________________________ lldb-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
