Re: How to get the current allocated total size of an ArrayList?
On 2/24/2011 4:24 AM, Lew wrote:
On 02/24/2011 07:14 AM, Roedy Green wrote:
On Wed, 23 Feb 2011 07:50:10 -0800, markspace<-@.> wrote, quoted or
indirectly quoted someone who said :
How can I find out the total size (in Bytes) which is currently
allocated by the ArrayList?
Occasionally I get an OutOfMemory exception. Can I prevent this by
preallocating everything in one step
in advance instead of doing this little by little with every add()?
It it the space needed for each string + some the overhead of the
array
Count on roughly 16 bytes overhead per object, 2 bytes per char, and 4
bytes for the length of each string.
Count on 4 bytes or 8 bytes per reference (if using 32/64 bit JVM) in
You cannot count on 8 bytes per reference in 64-bit JVMs. They also
support 4-byte references.
the array pointing to the Strings. There is some other junk, but that
is the bulk of it.
You can't preallocate space for the strings, other than my creating
the literal strings. Even then, you do it one string at a time.
And of course, with literal strings you put them into the intern pool,
not regular heap.
You can improve efficiency by guessing the correct size when you
allocate the ArrayList.
Nice myth.
It's a myth because it's next to impossible to guess right except in
very, very restricted cases, pretty much for which general algorithms
aren't suitable. If you are able to guess right about the size, you'd
want an array rather than an 'ArrayList' (or any other 'List').
Nice myth. Arrays are not a suitable collection type, they are a
primitive. If you know the exact size, ArrayList is suitable, or so is
using Arrays.asList(your,data,goes,here) (who's runtime type is
confusingly also named ArrayList, though its a private inner class)
I don't know how many times I've seen code complicated because the
author "optimized" to use Arrays rather than a properly abstracted
interface. I've even seen abuse of parallel arrays. Blargh.
Hotspot messes up your calculations under certain circumstances, too.
This is clearly a case where the OP should do the right thing instead of
what he's asking.
Bytes are not a good count for the "size" of Java objects, since byte
count changes if you're on a 32 vs 64 bit platform.
Also, the earlier estimate of bytes-per-string was wrong.
String in the JDK1.6 impl, String's contain the following fields:
char[] value; (4 bytes + array data + array length)
int offset; (4 bytes)
int count; (4 bytes)
int hash; (4 bytes)
PLUS the object header in the JVM for the String instance *and* the
array instance.
It gets even more complicated when some of the String instances are
obtained from String.substring(...) method calls, as those share the
underlying instance of the value array.
Java strings are definitely not as light-weight as C strings. This
isn't necessarily a bad thing, but one should be aware of this fact when
reasoning about them.
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>