Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / November 2005

Tip: Looking for answers? Try searching our database.

Java HashMap Size

Thread view: 
hrpreet - 24 Nov 2005 13:03 GMT
What can be maxium capacity of a HashMap so that performance of code is
not effected.Is it ok to store lackhs of data in a HashMap.If not then
which java collection is suitable for storing this large a data.
NullBock - 24 Nov 2005 13:55 GMT
Looking at the source, it looks like HashMap needs about 16 + 4 *
(loadfactor) bytes per entry, plus a few bytes.  Each bucket has four
fields, each field using four bytes.  The pointer to the bucket is also
necessary, and since it's hashed, there are more bucket pointers than
actual buckets.  This really isn't very many, and is probably dwarfed
by the memory need for the items being stored.  (IE, a simple string
can use hundreds of bytes.)

In any case, the upper limit for a hash table is the JVM memory
allocation, so even gargantuan hash maps shouldn't be a problem.  And
the great thing about hash maps is, even if they are gargantuan (ie,
millions of entries), the access time is still very fast.

Walter Gildersleeve
Freiburg, Germany
____________________________________________________
http://linkfrog.net
URL Shortening
Free and easy, small and green.
Thomas Hawtin - 24 Nov 2005 14:35 GMT
> Looking at the source, it looks like HashMap needs about 16 + 4 *
> (loadfactor) bytes per entry, plus a few bytes.  Each bucket has four
[quoted text clipped - 3 lines]
> by the memory need for the items being stored.  (IE, a simple string
> can use hundreds of bytes.)

It uses a bit more memory than this. Each object has (typically) a
pointer to the class information, a hash code and bits for use in
synchronisation and for garbage collection. Also on 64-bit systems, the
reference size will be doubled.

You could write a hash map with the entries inlined into the main array,
but it would tend to make any operation using Map.Entry slow.

The map may be many-to-one and the key may be shared or small, so memory
may be an issue in some obscure cases. A more likely (but still
unlikely) problem is GC pauses, particular if entries are medium lived.

> In any case, the upper limit for a hash table is the JVM memory
> allocation, so even gargantuan hash maps shouldn't be a problem.  And
> the great thing about hash maps is, even if they are gargantuan (ie,
> millions of entries), the access time is still very fast.

Yup, because the table grows, the number of entries necessary to sort
through on every access remains very small.

Tom Hawtin
Signature

Unemployed English Java programmer
http://jroller.com/page/tackline/



Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.