<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Apr 25, 2017 at 1:11 PM, Davide Italiano <span dir="ltr"><<a href="mailto:davide@freebsd.org" target="_blank">davide@freebsd.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On Tue, Apr 25, 2017 at 12:55 PM, Vedant Kumar via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
>> On Apr 24, 2017, at 5:37 PM, Scott Smith via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
>><br>
>> I've been working on improving the startup performance of lldb, and ran into an issue with llvm::HashString.  It works a character at a time, which creates a long dependency chain in the processor.  On the other hand, the function is very short, which probably works well for short identifiers.<br>
>><br>
>> I don't know how the mix of identifier length seen by lldb compares with that seen by llvm/clang; I imagine they're pretty similar.<br>
>><br>
>> I have to different proposals, and wanted to gauge which would be preferred:<br>
><br>
><br>
>> 1. Use xxhash instead.<br>
><br>
<br>
</span>I'd lean towards this option as we already have a copy of xxHash in<br>
lib/Support (llvm/Support/xxhash.h).<br>
We use it for computing the --build-id in lld as fast/non-crytographic<br>
hash variant and has proven to outperform other candidates (e.g.<br>
CityHash).<br></blockquote><div><br></div><div>That's actually why I suggested it, though AFAIK xxHash has more collisions than other hash algorithms.<br><br></div><div>xxHash outperforms CityHash?  <a href="https://github.com/rurban/smhasher/">https://github.com/rurban/smhasher/</a>  So many choices!<br><br></div></div></div></div>