Clearer byte range definition in get_range and get_ranges

[kylebarron]

Closes #155

[kylebarron]

cc @maxrjones A Rust match on two optional integers should be extremely cheap, and much cheaper than matching Python objects. I guess it really depends on the Python overhead of translating keyword arguments into rust. In terms of the Rust overhead of the option match, I'd expect that should be on the order of nanoseconds. Maybe any additional Python overhead would add up to a microsecond extra?

@maxrjones Would you be able to rerun your zarr benchmark from this branch?

[maxrjones]

@maxrjones Would you be able to rerun your zarr benchmark from this branch?

Happy to. Can you provide guidance on how to install the crate + bindings from git? usually I'd use uv add "obstore @ git+https://github.com/developmentseed/obstore@0ce55be897206d9867c6a1170be95c0c1ffc4d32" but that raises Package metadata name "test-env" does not match given name "obstore".

[kylebarron]

I think you need subdirectory=obstore https://stackoverflow.com/a/19516714

[kylebarron]

Just checked and

pip install git+https://github.com/developmentseed/obstore@0ce55be897206d9867c6a1170be95c0c1ffc4d32#subdirectory=obstore

worked for me

[maxrjones]

Sorry for the delay, took me a second to be able to use compiled code on the VEDA Hub and I wanted to run the benchmarks in us-west-2. Anyways, the new rate for loading a ~3.7GB array with Zarr is ~0.36% slower which IMO is acceptable.

[kylebarron]

No worries! Thanks for running it!

Anyways, the new rate for loading a ~3.7GB array with Zarr is ~0.36% slower which IMO is acceptable.

So it was 7.92s before this change and 7.948s after this change? I figure that could just be noise?

[maxrjones]

I used a instance with half as many cores so it was ~2x that time for each. If you'd be concerned about that relative difference, if real, I could record the individual timings to determine if there's a statistically significant difference.

[kylebarron]

Nah, that's good. Thanks for checking that benchmark!