search for: fnv1a

...bit) faster. That's on long strings. It would be worth checking the startup overhead for typically short identifiers in programs. See later on in the README: "When used in a hash table the instruction cache will usually beat the CPU and throughput measured here. In my tests the smallest FNV1A beats the fastest crc32_hw1 with Perl 5 hash tables. Even if those worse hash functions will lead to more collisions, the overall speed advantage beats the slightly worse quality. See e.g. A Seven-Dimensional Analysis of Hashing Methods and its Implications on Query Processing for a concise overvie...

...o. I can show how this can be done, but it's not currently on CRAN or even a well-defined package API. I have adapted a copy of R's serialize() [*] with the following changes: * Function bytecode and flags are ignored: f <- function() invisible() depcache:::hash(f, 2) # This is plain FNV1a-64 of serialize() output # [1] "9b7a1af5468deba4" .Call(depcache:::C_hash2, f) # This is the new hash [1] 91 5f b8 a1 b0 6b cb 40 f() # called once: function gets the MAYBEJIT_MASK flag depcache:::hash(f, 2) # [1] "7d30e05546e7a230" .Call(depcache:::C_hash2, f) # [1] 91 5f b8 a1...

...one, but it's not currently on CRAN or even > a well-defined package API. I have adapted a copy of R's serialize() > [*] with the following changes: > > * Function bytecode and flags are ignored: > > f <- function() invisible() > depcache:::hash(f, 2) # This is plain FNV1a-64 of serialize() output > # [1] "9b7a1af5468deba4" > .Call(depcache:::C_hash2, f) # This is the new hash > [1] 91 5f b8 a1 b0 6b cb 40 > f() # called once: function gets the MAYBEJIT_MASK flag > depcache:::hash(f, 2) > # [1] "7d30e05546e7a230" > .Call(depca...

Could you recommend any packages/functions that compute hash such that the source references and sexpinfo_struct are ignored? Basically a version of `serialize` that convert R objects to raw without storing the ancillary source reference and sexpinfo. I think most people would think of `digest` but that package uses `serialize` (see discussion

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. I don't know how the mix of identifier length seen by lldb compares with that seen by