| Age | Commit message (Collapse) | Author |
|---|
|
For hash map, using fnv1a is faster as it is a much simpler algorithm
we can afford to inline. For files murmur3 should win as it processes
bytes 4 by 4.
|
|
|
|
Also reverse the order of bytes, loading the most significant parts first,
and use bitwise "or" instead of addition.
|
|
The murmurhash implementation tries to read a sequence of four bytes as
a single little-endian uint32 value. This does not work on e.g. Linux/s390x;
https://buildd.debian.org/status/fetch.php?pkg=kakoune&arch=s390x&ver=2021.11.08-1&stamp=1645975425&raw=0
|
|
The real technical limit is with lines bigger than 2 GiB and buffers
with more than 2 Gi lines, refactor buffer loading to make it possible
to load those files.
Fix an overflow with the hash_data function at the same time
|
|
|
|
|
|
|
|
Until we switch to C++17 and can use the proper attributes there.
Fixes #1437
|
|
std::hash specialization is a pain to work with, stop using that, and
just specialize a 'size_t hash_value(const T&)' free function.
|
