Custom MapEntry to avoid Object Wrapper Creation

[Mark Proctor]

We are looking to get rid of our own custom hash map implementation - which doesn't implement Map (it's internal to our uses). One of the initial reasons for our own hash map implementation was the objects we put in the map can implement the Entry interface - this avoids creating additional Object wrappers on put, or finding the Entry on get and remove.

Looking over the code, I can see the MapEntry is unique for each and every implementation. So it's hard to get a generic approach here, but if I'm happy to tie to a specific collection implementation, what about allowing end users to extend MapEntry so that the put() no longer needs to create an additional object wrapper? I do appreciate the concerns on risks of exposing too much internalise, although this could be considered an "internal feature, extend at user risk" ?

Mark

[Sebastiano Vigna]

> On 23 Jan 2023, at 04:26, Mark Proctor <mdpr...@gmail.com> wrote:
>
> We are looking to get rid of our own custom hash map implementation - which doesn't implement Map (it's internal to our uses). One of the initial reasons for our own hash map implementation was the objects we put in the map can implement the Entry interface - this avoids creating additional Object wrappers on put, or finding the Entry on get and remove.
>

Slightly confused here. There is no Entry creation on put, remove, etc. in fastutil...

Ciao,

seba

[Mark Proctor]

I had a longer look at the code, it looks like MapEntry is only used when you need an iterator, which is great -  I only did a casual scan of the generated code before. Also looking at the code it seems you have a choice - EntryIterator and FastEntryIterator, the former creates a MapEntry per next(). The later creates a single MapEntry and re-uses it, which is nice.

The key part for us was the custom (Strategy) hashing implementation, if that works (for our needs) then I think we are good to try and replace our custom map/set implementations. Fyi this is for the Drools open source rule engine project. We had custom collections for our indexed objects, as part of our join network, that we are looking to replace - but we are very sensitive to performance regressions or increased object counts.

The last thing we need to investigate is potential worst case performance scenario of open vs linked map implementantions - as we don't want our community getting a nasty surprise if that has a big regression. Typically it's indexing strings and numbers, or composite combinations of those - so hopefully all ok.

Mark

[Sebastiano Vigna]

> On 23 Jan 2023, at 15:56, Mark Proctor <mdpr...@gmail.com> wrote:
>
>
> The last thing we need to investigate is potential worst case performance scenario of open vs linked map implementantions - as we don't want our community getting a nasty surprise if that has a big regression. Typically it's indexing strings and numbers, or composite combinations of those - so hopefully all ok.

Depending on the map size you might have a great improvement in the number of allocated objects, and thus memory footprint, garbage collection, etc. Deletions might be sometimes a bit slower as the map must be rearranged.

You might check how things go for strings, as Java's HashMap caches hash codes, and uses them to avoid performing equality checks. fastutil doesn't, but strings usually have a built-in copy of the hash code, so there impact is marginal, if any.

Ciao,

seba