Refactor the map core to its own module

[cuviper]

This moves the hash-agnostic IndexMapCore to its own module, and then cleans up the abstraction boundary in successive commits.

[cuviper]

I've been playing with using hashbrown's RawTable as the backend for IndexMap, and I already had this kind of refactoring as a result. I'm still not entirely satisfied with that, but I realized that the new organization could be beneficial on its own.

[cuviper]

FYI, I pushed hashbrown here: https://github.com/cuviper/indexmap/tree/shredded-potatoes

It will raise the MSRV to 1.32 for hashbrown's sake, unless we go through added effort to make this a conditional feature.

[bluss]

Really cool that it can be done, nice job!!, if the benchmark gains are significant it seems like we should use hashbrown no doubt. It also resolves our old question.. should we use unsafe to speed up indexmap? This way we outsource to a well-known and well tested implementation.

[bluss]

I guess that we unfortunately need clarification on the "experimental"-ness of the RawTable, if we depend on it for indexmap 1.x, even though it doesn't affect our API surface.

[cuviper]

Before we get too far on hashbrown, are you OK with the changes in this PR alone?

if the benchmark gains are significant it seems like we should use hashbrown no doubt.

So far it's a mixed bag, better on some, worse on others. It also seems highly sensitive to how codegen-units split, such that a seemingly insignificant tweak can cause big changes, even in the standard HashMap comparision benchmarks -- maybe we should set codegen-units = 1?

On a different metric, I found that the memory use (RSS) while running the benchmarks is consistently lower by quite a bit. However, the base IndexMapCore size will increase, because RawTable has 5 usize/pointers compared to the 3 it's replacing (mask: usize, indices: Box<[Pos]>).

This way we outsource to a well-known and well tested implementation.

I'm somewhat inclined to give this a lot of weight, myself, even if some performance is lost.

I guess that we unfortunately need clarification on the "experimental"-ness of the RawTable

@Amanieu, care to comment?

[bluss]

Before we get too far on hashbrown, are you OK with the changes in this PR alone?

Yes, sure. Nothing seems remotely controversial about it, unless I'm missing something (?), so it's just a very nice cleanup.

I'm somewhat inclined to give this a lot of weight, myself, even if some performance is lost.

Of course, as long as we have some tangible gains, like performance, for indexmap users, too.

[cuviper]

Nothing seems remotely controversial about it, unless I'm missing something (?), so it's just a very nice cleanup.

I don't think you're missing anything. 🙂

It will probably conflict with #126, but I can yield and rebase if you want to merge that first.
(The hashbrown change will probably make that one moot, but we'll deal with that later.)

[Amanieu]

The RawTable API is experimental in the sense that it may experience significant API changes and it could even be removed in the future if all its functionality becomes available directly on HashMap. However any such changes will be subject to a major version bump of the hashbrown crate so you don't need to worry about minor version bumps breaking the build.

[cuviper]

Sure, it's fine to have API changes with proper semver treatment -- that's a pretty safe "experimental". If we convert indexmap, I hope you might even involve us in the design of proposed changes.

[cuviper]

OK, rebase is green, let's go!