compute method on primitive maps cause boxing/unboxing

[gity]

The compute method on the maps require unboxing and boxing since the rely on the standard JDK 8 BiFunction instead of generating primitive type specific a BiFunction for each use case.

For example, Object2LongMap#computeLong

For example compare with Koloboke ObjLongMap#compute

It good that it is solved with Object2LongMap#computeLongIfAbsent, shame about computeLong

[incaseoftrouble]

The problem here is the parameter space explosion. Having type-specific BiFunctions is totally possible, but would require 8*8*8 = 512 additional classes (or maybe even 9*9*9). Moreover, this would require non-trivial changes to the way the sources are generated (since we need a triple of types instead of a key-value tuple).

If we only add the BiFunctions for this specific use case, we could restrict ourselves to Key x Key -> Value and Key x Value -> Value, I think - potentially, something like Key x Key -> ValueObject and Key x Value -> ValueObject should be added, too. This would still be a lot of classes but less work since one does not have to change the source generation too much.

[vigna]

Right. How does Koloboke do it? Hundreds of function classes?

[gity]

Koloboke API 1.0.0 has a function package with 281 classes in it.