How much memory does a hashtable use?

Question

Would a hashtable/hashmap use a lot of memory if it only consists of object references and int's?

As for a school project we had to map a database to objects (that's what being done by orm/hibernate nowadays) but eager to find a good way not to store id's in objects in order to save them again we thought of putting all objects we created in a hashmap/hashtable, so we could easily retrieve it's ID. My question is if it would cost me performance using this, in my opinion more elegant way to solve this problem.

Answer 1

It's impossible to answer this without some figures. How many objects are you looking to store? Don't forget you're storing the objects already, so the key/object reference combination should be fairly small.

The only sensible thing to do is to try this and see if it works for you. Don't forget that the JVM will have a default maximum memory allocation and you can increase this (if you need) via -Xmx

Answer 2

Minimally, you'd need an implementation of the Map.Entry interface with a reference to the key object and a reference to the value object. If either the the key or value are primitive types, such as int, you'll need a wrapper type (e.g. Integer) to wrap it as well. The Map.Entrys are stored in an array and allocated in blocks.

Take a look at this question for more information on how to measure your memory consumption in Java.

Answer 3

Would a hashtable/hashmap use a lot of memory if it only consists of object references and int's?

"a lot" depends on how many objects you have. For a few hundreds or a few thousands, you're not going to notice.

But typically the default Java collections are really incredibly inefficient when you're working with primitives (because of the constant boxing/unboxing from "primitive to wrapper" going on, like say "int to Integer") , both from a performances and memory standpoint (the two being related but not identical).

If you have a lot of entries, like hundreds of thousands or millions, I suggest using for example the Trove collections.

In your case, you'd use this:

TIntObjectHashMap<SomeJavaClass>

or this:

TObjectIntHashMap<SomeJavaClass>

In any case, that shall run around circle the default Java collections perf-wise and cpu-wise (and it shall trigger way less GC, etc.).

You're dodging the unnecessary automatic (un)boxing from/to int/Integer, the collections are creating way less garbage, resizing in a much smarter way, etc.

Don't even get me started on the default Java HashMap<Integer,Integer> compared to Trove's TIntIntHashMap or I'll go berzerk ;)