[Lldb-commits] [PATCH] D122974: prevent ConstString from calling djbHash() more than once

Luboš Luňák via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Thu Apr 28 15:32:57 PDT 2022


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



More information about the lldb-commits mailing list