1

What is the difference between Koloboke HashObjObj<K, V> and Java util HashMap<K, V>?

I am aware of the performance that Koloboke provides but there might be instances that K/V turn out to be a Integer/Long. Generally if known HashLongObjMap would be recommended but what happens when K/V come in as generics. From what I understand using HashLongObjMap uses long primitive as the key but what are the differences that come in when HashObjObjMap<Long, V> is used?

Eg:

HashLongObjMap<V> map1 = HashLongObjMaps.newImmutableMap();

Vs

HashObjObjMap<K, V> map2 = HashObjObjMaps.newImmutableMap();

Tom
  • 16,842
  • 17
  • 45
  • 54
sumsrv
  • 654
  • 3
  • 8
  • 25
  • 1
    http://java-performance.info/large-hashmap-overview-jdk-fastutil-goldman-sachs-hppc-koloboke-trove/ – assylias Feb 10 '16 at 13:13
  • @assylias: Seems using `HashObjObjMap` would hit the performance even if K is `Long`. Isn't there a way the library itself calls `HashLongObjMap` or `HashIntObjMap` if `K` is one of the data types? May be I'll try look out for a way. – sumsrv Feb 10 '16 at 13:32

1 Answers1

1

The difference between HashObjObjMap and java.util.HashMap is algorithm and itnernal memory layout. HashObjObjMap is an open-addressing hash table with linear probing, storing keys and values in the same flat Object[] array, in interspersed order: [key1, value1, key2, value2, ...]. Entry objects don't exist, they are created only when required by Map API (i. e. entrySet() iteration). HashMap is a hash table with separate chaining, keys and values are stored in separate Entry objects.

HashLongObjMap stores keys as primitive longs, HashObjObjMap has ordinary Object keys.

HashObjObjMap<Long, V> cannot call HashLongObjMap internally because they have slightly different contract, e. g. the latter cannot hold null key. Also I don't see much sense in it, if you need long keys you should just explicitly use HashLongObjMap yourself instead of HashObjObjMap and relying on some implicit "optimizations".

leventov
  • 14,760
  • 11
  • 69
  • 98
  • Need it this way as it is not guaranteed that the keys will be long. `It might be short, int, byte, etc`. Using **Obj** to cover all would impact performance, although using **long** for all cases is another alternative. But the data set is huge and so I'm willing to keep it flexible. It is required in the middle of a method. Interface/Abstract class and separate implementations make it too complex due to good number of permutations and other associated limitations. – sumsrv Feb 11 '16 at 12:10
  • I don't see how ObjObj resolving as LongObj would solve this problem. Common base of all LongObj, IntObj, ShortObj maps is simply `java.util.Map` (raw). You can use it – leventov Feb 11 '16 at 12:15