1

Case 1 :

One HashMap with 1,00,000 entries

Case 2 :

Two HashMaps with 50,000 entries each.

Which of the above cases will take more execution time and more memory? Or is there a significant difference between the two?

Is it feasible to replace one HashMap of large number of entries with two HashMaps of lesser number of entries?

Eran
  • 387,369
  • 54
  • 702
  • 768
Vivone
  • 83
  • 10
  • 1
    Try it and examine the results. – Kayaman Nov 28 '14 at 09:34
  • What type of key you are using ? – Vishal Nov 28 '14 at 09:35
  • 1
    Theres a pretty question+awnser on this post http://stackoverflow.com/questions/7115445/what-is-the-optimal-capacity-and-load-factor-for-a-fixed-size-hashmap . It should answer your question and its pretty interesting. – ug_ Nov 28 '14 at 09:52
  • 100,000 is not a big number - so if you have a performance issue, either your performance target is too high for your hardware or there is a problem with your code, which you can find by using a profiler. – assylias Nov 28 '14 at 10:06

4 Answers4

2

You're better off with a single hash map.

Look-ups are very efficient in a hash map, and they're designed to have lots of elements in. It'll be slower overall if you have to put something in place to search one map and then look in the other one if you don't find it in the first one.

(There won't be much difference in memory usage either way.)

If it's currently too slow, have a check that your .hashCode() and .equals() are not inefficient.

chiastic-security
  • 20,430
  • 4
  • 39
  • 67
2

The memory requirements should be similar for the two cases (since the HashMap storage is an array of Entries whose size is the capacity of the map, so two arrays of 50K would take the same space as one array of 100K).

The get() and put() methods should also have similar performance in both cases, since the calculation of the hash code of the key and the matching index is not affected by the size of the map. The only thing that may affect the performance of these operations is the average number of keys mapped to the same index, and that should also be independent of the size of the map, since as the size grows, the Entries array grows, so the average number of Entries per index should stay the same.

On the other hand, if you use two smaller maps, you have to add logic to decide which map to use. You can try to search for a key in the first map and if not found, search in the second map. Or you can have a criteria that determines which map is used (for example, String keys starting in A to M will be stored in the first map, and the rest in the second map). Therefore, each operation on the map will have an additional overhead.

Therefore, I would suggest using a single HashMap.

Eran
  • 387,369
  • 54
  • 702
  • 768
1

The performance difference between using one or two HashMaps should not matter much, so go for the simpler solution, the single HashMap.

But since you ask this question, I assume that you have performance problems. Often, using a HashMap as a cache is a bad idea, because it keeps a reference to the cached objects alive, thus basically disabling garbage collection. Consider redesigning your cache, for example using SoftReferences (a class in the standard Java API), which allows the garbage collector to collect your cached objects while still being able to reuse the objects as long a they are not garbage collected yet.

Hoopje
  • 12,677
  • 8
  • 34
  • 50
0

as everyone mentioned, you should be using one single hash map. if you having trouble with 100k entries then there is a major problem with your code. here is some heads up on hash map:

  1. Don't use too complex objects as key (in my opinion using object string as key is as far as you should go for HashMap.
  2. if you try to use some complex object as key make sure your equals and hashCode method are as efficient as possible as too much calculation within these method can reduce the efficiency of hashmap greatly
nafas
  • 5,283
  • 3
  • 29
  • 57