llunak added a comment. In D122974#3480686 <https://reviews.llvm.org/D122974#3480686>, @dblaikie wrote:
> In D122974#3424654 <https://reviews.llvm.org/D122974#3424654>, @JDevlieghere > wrote: > >> ... >> struct HashedStringRef { >> const llvm::StringRef str; >> const unsigned full_hash; >> const uint8_t hash; >> HashedStringRef(llvm::StringRef s) : str(s), full_hash(djbHash(str)), >> hash(hash(str)) {} >> } ... > The external code shouldn't be able to create their own (ctor > private/protected, etc) - the only way to get one is to call `StringMap` to > produce one. But what if I don't want StringMap to compute the hash at all? There's still that 10-15% of CPU time spent in djbHash() when debug info uses exactly[*] that (and LLDB's index cache could be modified to store it). Which means it can be useful for StringMap to allow accepting precomputed hash, and then what purpose will that HashedStringRef have? (*) Well, not exactly, the seed is different. Doesn't seem an impossible problem to solve though. > (these functions could/should probably still then assert that the hash is > correct in case of that underlying mutation - though someone could argue > that's overkill and I'd be open to having that discussion). I'd prefer to have that discussion. If your argument is perfection, then let's do the full monty. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D122974/new/ https://reviews.llvm.org/D122974 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
