Use papaya instead of dashmap

[arendjr]

This PR replaces uses of dashmap in the Cache with papaya: https://github.com/ibraheemdev/papaya/
papaya is designed for read-heavy workloads, which seems quite fitting for your caching use case. We've also switched to it in Biome and are getting good results.

Note this PR currently depends on an unmerged feature I proposed, so I'm leaving it in Draft until this is merged: ibraheemdev/papaya#45

Performance results on my machine:

Benchmarking resolver/single-thread: Collecting 100 samples in estimated 5.0029 s (91k iteresolver/single-thread  time:   [53.564 µs 53.785 µs 54.015 µs]
                        change: [−13.249% −11.794% −10.385%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 8 outliers among 100 measurements (8.00%)
  2 (2.00%) high mild
  6 (6.00%) high severe
Benchmarking resolver/multi-thread: Collecting 100 samples in estimated 5.0311 s (152k iteresolver/multi-thread   time:   [37.287 µs 39.436 µs 41.322 µs]
                        change: [−14.069% −10.050% −5.5926%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 19 outliers among 100 measurements (19.00%)
  19 (19.00%) high severe
Benchmarking resolver/resolve from symlinks: Collecting 100 samples in estimated 5.2374 s resolver/resolve from symlinks
                        time:   [14.284 ms 14.309 ms 14.334 ms]
                        change: [−7.1326% −6.8864% −6.6154%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 2 outliers among 100 measurements (2.00%)
  2 (2.00%) high mild

So a roughly 10~11% speedup on the first two benchmarks, and almost 7% on the one involving symlinks.

[codspeed-hq]

CodSpeed Performance Report

Merging #356 will not alter performance

_{Comparing arendjr:papaya (4966f7f) with main (fede8dc)}

Summary

✅ 3 untouched benchmarks

[ibraheemdev]

Out of curiosity, are the benchmark results any better if you create the HashMap with the following configuration?

papaya::HashMap::builder()
    .resize_mode(papaya::ResizeMode::Blocking)
    .collector(seize::Collector::new().epoch_frequency(None))
    .build()

By default, papaya is configured to avoid tail latency spikes and prevent memory usage spikes caused by stalled threads. This is useful for server workloads but maybe less so for short-lived CLI applications (see ibraheemdev/papaya#46). Although it's possible that this project is used in LSP servers, so it might something you also care about :)

[arendjr]

@ibraheemdev Trying out the throughput-optimized configuration too. Just to clarify: Can the memory spikes be caused by stalled threads, even if they're not holding on to a pin?

[ibraheemdev]

@arendjr No, the issue would be a thread holding on to a guard without dropping it. Epochs detect stalled threads and allow finer-grained reclamation of objects that they haven't accessed yet. This would be useful when holding a guard on an iterator, for example.