HashMap load factor and performance

Question

Hi,
Does anyone know why an increase in the load factor of a HashMap decreases lookup performance?
Furthermore, assuming that 99% of the time you will be reading from
the HashMap and writing(put) a well know amount only 1% of the time.
Should the load factor be .01 to get the best performance?
Perhaps I should use a different data structure? I am trying to
load String name/value pairs in a data structure. The loading usually occurs once, but the data can be reloaded. The data will only be
accessed via get(name). Nothing else matters. I will submit a name and want the value back. Practically, speaking the performance is not even an issue in my application, but I want to be aware of the issues involved and not blindly use the structure. I don't want to study the source. I have searched the web, but did not find anything that clearly deals with these issues. I am hoping someone who has already spent the effort can shed some light.
Thanks,
elisahak

Answer 1

If you read any book on performance, they'll tell you to optimise where you need it. And you work this our through profiling - where you need to optimise might not be where you think you'll need to optimise.
Anyway, assuming that you've determined that your bottleneck will be your hashtable, and you wish to tune it: if you read any book on performance, they'll tell you to measure - if you refactor/redesign/reconfigure because you think it'll be more efficient, and do verify that it is more efficient, then you're wasting your time (no pun intended).
So, I would suggest that you write a method:
timeTypicalUsage(final int initialCapacity, final float loadFactor) {
   ... add loads of stuff
   ... read loads of stuff (maybe do this in a loop 99 times so that
   you reflect your "typical usage".
} Then call this method several times, with various load factors and time each call. If you're using JUnit, it'll automatically time the invocations for you.
Just remember that the first invocations of a method are typically the slowest, as class loaders, JIT, etc. are all only "warming up". And that you should be testing with enough invocations that each test method take at least several seconds, if not tens of seconds, otherwise, other any overhead starts to become significant.