cp: Use ahash

[oech3]

No description provided.

[oech3]

cp_large_file[16]
+1% 395.2 µs -> 389.8 µs

cp_archive_balanced_tree[(5, 4, 10)]
+1% 77.3 ms -> 76.5 ms

cp_recursive_wide_tree[(6000, 800)]
+1% 188.4 ms -> 187.1 ms

cp_recursive_deep_tree[(120, 4)]
+1% 13.5 ms -> 13.4 ms

cp_recursive_balanced_tree[(5, 4, 10)]
+1% 71.9 ms -> 71.5 ms

cp_preserve_metadata[(5, 4, 10)]
0% 74.1 ms -> 73.8 ms

[github-actions]

GNU testsuite comparison:

GNU test failed: tests/date/date-locale-hour. tests/date/date-locale-hour is passing on 'main'. Maybe you have to rebase?
Congrats! The gnu test tests/cut/bounded-memory is no longer failing!
Note: The gnu test tests/cut/cut-huge-range is now being skipped but was previously passing.

[my4ng]

Would it make sense to create types in uucore, something like.

pub type UHashMap<K, V> = ahash::HashMap<K, V>;
pub type UHashSet<T> = ahash::HashMap<T>;
pub use ahash::HashMapExt as UHashMapExt;
pub use ahash::HashSetExt as UHashSetExt;

This would reduce the number of PRs, and create a central place that makes potential later replacements since only the alias needs to be changed instead of at each use site.

[oech3]

previously tried it. but failed.

[oech3]

Each Hashers are optimized for different sizes. So the name UHash* is bit rough.
Also .with_capacity() does not work with some hasher...

[my4ng]

Just my two cents, I think we can all agree that siphash is slow for DOS protection, and there are a wide range of faster hashes, e.g. ahash, fxhash, rapidhash, xxh3, rustc-hash, you name it. It's true that they have different performance characteristics with different input sizes (u64/filename/text/etc.), but much of this is platform/input dependent. More importantly, having different ones for each is not worth the added complexity/security implications nor the reduced maintainability. I think a good enough common hashing algorithm would make more sense.

[oech3]

I'd like to have 2 hasher at leats for (reciently dropped Fnv).