clayborg added a comment. In D115324#3857081 <https://reviews.llvm.org/D115324#3857081>, @dblaikie wrote:
> Been experimenting with this recently and I noticed that loading in the > cached indexes seems to do a lot of loading - specifically interning a lot of > strings from the index and the symtab. Does this happen when reading a > built-in index (apple_names/debug_names) (I don't have an immediately easy > way to test this, or I Would've before asking)? I'd be surprised if that was > the case, which is also confusing me as to why it's the case for these cached > indexes? I'd have expected the cached index to look basically the same as the > apple_names/debug_names builtin index and have similar performance > properties, but maybe that's not the case? Yeah, the caches are currently designed to just serialize the cache to disc and allow it to be loaded into the same data structure as is used when the cache isn't used. The DWARF indexes are more efficient where there is a base class that represents the cache, and the manual index will create its own data structures and then do lookups using the base class' API. It allows the API calls to do the lookups as efficiently as possible without interning any strings. An improvement to this caching could do the same kind of thing, but that isn't what we have right now. We would need to continue to serialize/deserialize the symbol table, but the symbol table index and debug info index could be modified to indirect the cache lookups through a base class so the serialized indexes could be made more efficient. The index cache is purely a serialize/deserialize of the same cache structure that is used when manually parsing and indexing. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D115324/new/ https://reviews.llvm.org/D115324 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
