Feature request: More fine grained configurability of `ORD_CHUNK_SIZE`

[bryal]

Hi, all you contributors, and thanks for a great library!

I'm considering using this library for a project. Specifically imbl::OrdMap. Only blocker is that the default value of ORD_CHUNK_SIZE (previously 64, currently 16 on main) is a bit too low for my particular needs. My keys and values are all u64 IDs, and a bigger ORD_CHUNK_SIZE would result in lower memory use and is a better tradeoff for my purposes. Specifically, ORD_CHUNK_SIZE=128 seems to yield the best results with my particular data and usage patterns.

Could you consider splitting up the small-chunks feature into something more fine-grained like ["ord-chunk-size-6", "ord-chunk-size-16", "ord-chunk-size-64", "ord-chunk-size-128"]? Thanks!

[jneem]

I think it's very reasonable to give more control over the chunk size, but I'm not sure if a crate-wide feature is the way to go: what if you want an OrdMap with u64 keys, but then also one with larger keys? I'm tempted to suggest making it a generic parameter instead. We could hide the complexity by having a type alias at the top level that sets a reasonable default (like the way we handle Arc vs Rc). What do you think?

By the way, the small-chunks feature wasn't really intended to be used for this -- it's really for testing, because if the chunks are big then you never hit certain corner cases.

[bryal]

Yeah that makes more sense, for sure. Now that you mention it - and again, from the perspective of my own project - I'd probably want to use OrdMap in a couple of other places as well, where the keys are of the same type as before but where the values are not trivially Copyable. It would indeed be more useful then if I could pick different chunk sizes depending on the occasion.

[jplatte]

Due to how generic parameters work (even with defaults, via type alias or directly in the type definition), this could break type inference in some cases, so might have to be handled as a breaking change (even though Rust API guidelines says type inference breakage is minor). Just FYI :)