<div dir="ltr"><div><div><div><div><div><div><div>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></div>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></div>I have to different proposals, and wanted to gauge which would be preferred:<br><br></div><div>1. Use xxhash instead.<br></div><div><br></div>2. Use the Intel native crc32q instruction to process 8 bytes at a time, then fall back to byte at a time.  Non sse 4.2 capable processors (either early or non Intel/AMD x86) would use the existing algorithm, or possibly #1 above.<br><br></div>For my test, both result in approximately the same # of cycles (within 0.5%).<br><br>#1 uses 3+% more instructions.<br></div>#2 requires (realistically) runtime detection of cpu capabilities, because distributions would want generic x86/x86_64 compatible binaries, not separate binaries per cpu feature.<br><br></div>I'm leaning toward #1 despite the instruction increase.  My only worry is the effect on compile times for code with lots of short identifiers.  I haven't tested that though (and I don't have a suitable benchmark suite for that) so for all I know I'm worrying about nothing.<br><br></div>FYI the improvement is approximately 11.5% reduction in cycles for my lldb test (b main, run, quit), so IMO it's pretty significant.<br><br></div>