Question

I have a (java) class with about 10 attributes, many of them potentially staying uninitialized and are not accessed during lifetime of an object.

Therefore I’m considering using a Map<String,Object> as an attribute-name -> attribute-value map instead of a lot of fields, in order to save resources.
Now I am wondering, if there exist any offical or unofficial rules, when and how to decide on one of the described possibilities. How many attributes should a class have, before I should consider using such a map? Should I use it at all?

Thanks in advance for your advice/opinions on that.

Answer 1

Okay so you’re doing this to save memory I assume because clearly you’re not saving CPU resources by accessing a map instead of a field. So let’s see how good that works out: (assuming 64bit JVM without compressed oops – which is unrealistically but shouldn’t change the results too much, you can compute it yourself easily)

Basically a field in java will never take up more than 8bytes (well word size for references). So this means for your class with 10 fields, assuming all are unused the best we can save are 8*10 bytes = 80byte.

Now you want to replace this with one HashMap instead – that means we already use up 8 extra bytes for that. Also the HashMap is always initialized so we get the overhead of: 2 words header + reference + 3 ints + float + 1 array (2 words overhead, 4byte size, 16 references by default) which takes up 182 bytes of memory.

May I congratulate you to saving a whopping -110 bytes!

PS: I think the smallest possible default value for the backing array of the hashset is 2, so you could use that and come out about even. But as soon as you store objects in the set, you get additional overhead from the Wrapper objects used by the class. So really it’s a bad idea.