Map default size Vs Intial size

[Mano Pragadeeshwar]

From memory point of view what is the difference between the following 2 declarations?

Map<String,String> myMap = new HashMap<String, String>(2);
Map<String,String> myMap = new HashMap<String, String>();

Is there an advantage of declaring Map size from memory point of view?

[Mike Simmons]

The one with no declared capacity will have a default capacity of 16, while the one with 2 declared will have 2. Unless, of course, you put enough elements in to expand them beyond their initial capacities. I suppose the size of 2 is a slight advantage in terms of memory, if you don't need any more than that. But it's extremely unlikely to matter to anyone, unless you are creating a LOT of these maps.

[Mano Pragadeeshwar]

Thank you Mike. I declared the size of the Map since I know for sure that is the number of elements.

[Winston Gutkowski]

Mano Pragadeeshwar wrote:Thank you Mike. I declared the size of the Map since I know for sure that is the number of elements.

That's almost always the best way to go, since it makes loading the Map optimally fast.

However, a HashMap with 2 elements strikes me as possibly over-engineering.

Winston

[Mike Simmons]

Winston Gutkowski wrote:

Mano Pragadeeshwar wrote:Thank you Mike. I declared the size of the Map since I know for sure that is the number of elements.

That's almost always the best way to go, since it makes loading the Map optimally fast.

Well, thing is, if you put 2 entries into such a map, it's going to resize to capacity 4, because the default load factor is .75. It may be tempting to make the load factor 1 instead. But then there's another issue - at size 2 or 4, there's a considerably higher chance of hash collision than there is at at size 16. So if you're talking about speed, rather than memory, the default size 16 will probably work better. Does this really matter? Probably not, except as an example that such micro-optimizations are not as straightforward as they seem.

Winston Gutkowski wrote:However, a HashMap with 2 elements strikes me as possibly over-engineering.

Maybe. But often there are APIs that require a Map for some reason. For the common case that you need to create such a map but it doesn't need to be editable later, I would recommend Google Guava's ImmutableMap:

Map<String, String> map = ImmutableMap.of(
    "one", "uno",
    "two", "dos",
    "three", "tres"
);

This is equivalent to the more tedious

Map<String, String> innerMap = new HashMap<String, String>();
innerMap.put("one", "uno");
innerMap.put("two", "dos");
innerMap.put("three", "tres");
Map<String, String> map = Collections.unmodifiableMap(innerMap);

but the Google version, aside from being more compact, also creates a map of the appropriate size, automatically.

[Winston Gutkowski]

Mike Simmons wrote:Well, thing is, if you put 2 entries into such a map, it's going to resize to capacity 4, because the default load factor is .75.

True. I always though that was an odd way to do things. If I supply a size, it seems reasonable to assume that I'm doing so because I know how many elements I'm going to add; and therefore it would seem sensible to allocate a map capacity that won't need re-hashing.

Winston

[Mike Simmons]

Well, capacity isn't exactly the same as the number of elements a hash table can hold, anyway. You could put 100 elements in a table with size 2 for example - it's just that you would have ~50 collisions in each bucket. And you can have collisions even when the size is less than the capacity. That's why they pick 0.75 as a default. No value would really guarantee no collisions - they just try to pick a reasonable value there.

[Winston Gutkowski]

Mike Simmons wrote:Well, capacity isn't exactly the same as the number of elements a hash table can hold, anyway. You could put 100 elements in a table with size 2 for example - it's just that you would have ~50 collisions in each bucket. And you can have collisions even when the size is less than the capacity. That's why they pick 0.75 as a default. No value would really guarantee no collisions - they just try to pick a reasonable value there.

I think maybe we're talking at cross-purposes here. If I say
new HashSet(50);
I think it can be reasonably assumed that I want to load 50 values into the resulting Set.

If that's the case, then it would seem sensible to me to make the initial capacity of the Set sufficient to be able to do that without having to re-hash, which I suspect would require space of at least (50 / load-factor) + 1 buckets. However, last time I looked, the class didn't seem to do that.

Winston

[Martin Vashko]

Mike Simmons wrote:

Map<String, String> innerMap = new HashMap<String, String>();
innerMap.put("one", "uno");
innerMap.put("two", "dos");
innerMap.put("three", "tres");
Map<String, String> map = Collections.unmodifiableMap(innerMap);

I would do

Map<String, String> map = Collections.unmodifiableMap(new HashMap<String, String>()
    {{
        put("one", "uno");
        put("two", "dos");
        put("three", "tres");
    }}
);

but I agree that the Guava version is still more pleasant.

[Rob Spoor]

I hate that code. You're creating an anonymous inner class only to automatically add some entries.

[Martin Vashko]

Rob Spoor wrote:I hate that code. You're creating an anonymous inner class only to automatically add some entries.

Yes, but what's the deal?

One more anonymous class? That in itself cannot be a problem; I've got tens, if not hundreds others in my code, mostly Swing listeners. And some of them are created for very simple purposes, certainly classifiable as "only to ...".

In this case, the benefit is that I don't publish the modifiable version of the map anywhere. That alone is a very good reason to me. But I'd be tempted to do this even for simple (modifiable) map, since the declaration and initialization would be completely tied together; I always try to keep them together whenever possible.

On the other hand, I don't remember actually constantly initializing a map ever. I'd be still eager to hear your reasoning, though

[Rob Spoor]

It's just personal style. If this is for constructing a static field, I would use a static initializer block. If it is for an instance field or local variable, I'd probably create a method. Both will shield the temporary map variable.

[Mike Simmons]

Winston, you might appreciate this. On JavaPosse's latest podcast, Tor just discovered the same thing we were talking about, that using HashSet's constructor as if you're telling it the number of elements do expect does not avoid resizing. They rant on it a bit, agreeing with you about what they expected it should do. It's in the Aug 10 podcast, around 0:59-1:07. Bottom line: use Guava, which does what you want here.

[Winston Gutkowski]

Mike Simmons wrote:Winston, you might appreciate this. On JavaPosse's latest podcast, Tor just discovered the same thing we were talking about, that using HashSet's constructor as if you're telling it the number of elements do expect does not avoid resizing. They rant on it a bit, agreeing with you about what they expected it should do. It's in the Aug 10 podcast, around 0:59-1:07. Bottom line: use Guava, which does what you want here.

Ah. Cheers for that. I kind of figured it did; but it's always nice to be vindicated. I'll have to check out Guava one of these days.

Winston