(fix): cache partial decoder

[ilan-gold]

Fixes #90 (hopefully) - I benchmarked and performance (at least relatively speaking) did not go down, but also did not go up, although our benchmarks are probably not really checking for this behavior.

I went with HashMap because I couldn't see a reason to use BTreeMap (I see it's used elsewhere and that people in rust seem to use it as a drop-in replacement for HashMap because it's faster sometimes? Not really familiar with this TBH).

I am also not sure the key is the right thing to hash on - the "key" here would be a shard, and we want to share the decoder per shard, right?

[LDeakin]

the "key" here would be a shard, and we want to share the decoder per shard, right?

Yep! The partial decoder for the sharding codec retrieves and decodes the shard index only once.

However, the partial decoder cache should only live as long as the batch of requests in retrieve_chunks_and_apply_index. Otherwise, it would perpetually grow and become stale after subsequent writes. I should document this better, but partial decoder initialisation can perform store and codec operations (and may even decode entire chunks with certain codecs!).

• https://docs.rs/zarrs/latest/zarrs/array/struct.Array.html#optimising-reads
• https://book.zarrs.dev/arrays/array_read.html#reading-multiple-chunk-subsets

So my recommendation is to avoid locks and:

1. Identify the unique chunks and create partial decoders for each in parallel.
2. Run partial_decode_into in parallel for each chunk subset

[ilan-gold]

Separately there seems to be an error about typesize which I would guess is somehow related to my work on that zarr-developers/numcodecs#713

[ilan-gold]

Yup, https://github.com/zarr-developers/numcodecs/blob/58bc9c4da74e06fbec985d4235f912b31d4d31f6/numcodecs/abc.py#L79-L95 means it is now part of the configuration. So we can probably ignore it, will open a separate PR

[ilan-gold]

Seems like I did 1. by constructing a HashMap of the keys that require partial mapped to their WithSubset and then parallel-iterate to create tuples that have the key and the decoder before updating the HashMap representing the mapping of key to decoder. 2. Should already be handled

[ilan-gold]

I think there is a cleaner way to do this...

[LDeakin]

Nice! Just a minor nit on Option -> Result + ensuring that the chunk concurrent limit is used.