Feature Request: Add a generic parameter for choosing fallback map type

[biryukovmaxim]

I'd like to propose a backward-compatible enhancement that would make the crate more flexible without changing its default behavior.

Feature Request

Add a generic type parameter that allows choosing the fallback map type used when the inline capacity is exceeded.

Today, when the number of elements grows beyond N, SmallMap falls back to a fixed HashMap. This works well for many cases, but some applications would benefit from selecting a different map backend.

Motivation

Different workloads have different needs once maps exceed the inline capacity:

Faster full-map iteration
Some backends (such as IndexMap) have more cache-efficient iteration over medium-sized maps, especially when scanning all entries frequently.

Inline behavior remains unchanged.
Existing users see no behavior changes.

If this sounds reasonable, I’d be happy to attempt a draft PR.

[ihciah]

Thanks for the proposal.

A quick update: the current main branch (unreleased) already supports specifying different Hashers for inline and heap maps. This version features significant optimizations, specifically a more compact memory layout and linear search for smaller datasets to bypass hash calculation overhead. I suggest evaluating the performance difference between this current implementation and IndexMap in your case.

However, abstracting the heap map backend (e.g., to support IndexMap generically) would impose heavy trait bound constraints on the public API. Given the complexity, I suggest implementing this as a separate struct or enum(like SmallIndexMap? I'm not good at naming) rather than complicating the core SmallMap definition.

Regarding the "cache-efficient iteration" you mentioned: Could you add a benchmark case for this scenario? Having a reproducible benchmark in the codebase would be valuable for us to continuously track performance and drive future internal optimizations.