Vector<T> length in bytes

[ivan.kataitsev]

Hello, Guys! I have 'Vector<T> elements ' and want to get it length,
express in bytes. Any idea that i have is firstly make Vector<T> to
byte array and then get the length of array. Who can suggest smartier
way?

 

[Mark Space]

Hello, Guys! I have 'Vector<T> elements ' and want to get it length,
express in bytes. Any idea that i have is firstly make Vector<T> to
byte array and then get the length of array. Who can suggest smartier
way?

I don't think you can. First, Java has nothing to do with bytes, most
of the time. You are completely insulated from the hardware and the
memory your objects occupy. It can serialize an object to storage, or a
network, but that's a different idea than the memory footprint.

If you want to fit your objects into a byte [], you need to design a
custom method to do that. Java can't even convert a Vector to a byte
[], so there's no way to get the size of said byte[] either.

Why do you think you need to do this?

 

[ivan.kataitsev]

If you want to fit your objects into a byte [], you need to design a

custom method to do that. Java can't even convert a Vector to a byte
[], so there's no way to get the size of said byte[] either.

But the number of the elements of the byte[] is the size of byte[] in
bytes, isnt it?

 

[Mark Space]

If you want to fit your objects into a byte [], you need to design a
custom method to do that. Java can't even convert a Vector to a byte
[], so there's no way to get the size of said byte[] either.

But the number of the elements of the byte[] is the size of byte[] in
bytes, isnt it?

No. byte [] will occupy a bit more than that because, at minimum, the
reference will use up a few bytes too. In other words, byte [] b = new
byte[10]; will occupy about 18 bytes, at least, because a reference (the
"b") takes up about 8 bytes on it's own.

And I don't think you are guaranteed that the JVM is using octets (fancy
word for bytes) to implement the byte type in Java. It could be using
machine words which might be 4 bytes long. So the array about might be
48 bytes - 8 bytes for the reference and 4 bytes each for the elements,
each of which will have 3 bytes unused.

Java is not C. Java is a long ways away from the machine. It does that
for portability. If you need access to machine elements like real
bytes, you should use C. So that brings me back to, why do you need this?

I found some stuff that I was looking for before I sent my first post:

You can use java.lang.Runtime to determine how much memory you have
left, and how much you are using. If you make lots of Vector<T>'s you
can get a statistical approximation to the amount of space they occupy.
That's what I've seen done for other sorts of objects. Do a search
for "java memory footprint" I think you'll find the articles describing
what I'm talking about. That's how I know a reference is about 8 bytes
most of the time, because other folks have done the research.

<http://java.sun.com/javase/6/docs/api/java/lang/Runtime.html>

<http://java.sun.com/docs/books/performance/1st_edition/html/JPRAMFootprint.fm.html>

 

[Roedy Green]

Hello, Guys! I have 'Vector<T> elements ' and want to get it length,
express in bytes. Any idea that i have is firstly make Vector<T> to
byte array and then get the length of array. Who can suggest smartier
way?

see http://mindprod.com/jgloss/sizeof.html

The size in bytes is known in Java. So you an compute with a
multiplication.

 

[Roedy Green]

First, Java has nothing to do with bytes, most
of the time.

You have the DataOutputStream representation which is that the JVM
emulates internally. The ACTUAL internal form could be wildly
different, e.g. big/little endian, 128-bit registers ...

 

[ivan.kataitsev]

If you want to fit your objects into a byte [], you need to design a
custom method to do that. Java can't even convert a Vector to a byte
[], so there's no way to get the size of said byte[] either.

But the number of the elements of the byte[] is the size of byte[] in
bytes, isnt it?

No. byte [] will occupy a bit more than that because, at minimum, the
reference will use up a few bytes too. In other words, byte [] b = new
byte[10]; will occupy about 18 bytes, at least, because a reference (the
"b") takes up about 8 bytes on it's own.

And I don't think you are guaranteed that the JVM is using octets (fancy
word for bytes) to implement the byte type in Java. It could be using
machine words which might be 4 bytes long. So the array about might be
48 bytes - 8 bytes for the reference and 4 bytes each for the elements,
each of which will have 3 bytes unused.

Java is not C. Java is a long ways away from the machine. It does that
for portability. If you need access to machine elements like real
bytes, you should use C. So that brings me back to, why do you need this?

I found some stuff that I was looking for before I sent my first post:

You can use java.lang.Runtime to determine how much memory you have
left, and how much you are using. If you make lots of Vector<T>'s you
can get a statistical approximation to the amount of space they occupy.
That's what I've seen done for other sorts of objects. Do a search
for "java memory footprint" I think you'll find the articles describing
what I'm talking about. That's how I know a reference is about 8 bytes
most of the time, because other folks have done the research.

<http://java.sun.com/javase/6/docs/api/java/lang/Runtime.html>

<http://java.sun.com/docs/books/performance/1st_edition/html/JPRAMFoot...>

=) Mark, thank u for your help, but in context of my task i need to
know exactly the "length" in bytes, not memory allocation of byte[].
After some actions all data will be send to the some output stream anf
to make correct blocks of data i need to know the subj. Anyway, thanx
for ur help.

 

[Andrea Francia]

=) Mark, thank u for your help, but in context of my task i need to
know exactly the "length" in bytes, not memory allocation of byte[].
After some actions all data will be send to the some output stream anf
to make correct blocks of data i need to know the subj. Anyway, thanx
for ur help.

If you wanna know the serialized size of the object you can serialize
the object in a ByteArrayOutputStream and the call the size() method.

http://java.sun.com/javase/6/docs/api/java/io/ByteArrayOutputStream.html

 

[Lew]

=) Mark, thank u for your help, but in context of my task i need to
know exactly the "length" in bytes, not memory allocation of byte[].
After some actions all data will be send to the some output stream anf
to make correct blocks of data i need to know the subj. Anyway, thanx
for ur help.

If you wanna know the serialized size of the object you can serialize
the object in a ByteArrayOutputStream and the call the size() method.

http://java.sun.com/javase/6/docs/api/java/io/ByteArrayOutputStream.html

This, of course, is not related to the memory it occupies in the JVM.

In general there is no way to know how much memory a Vector occupies. Do you
count the objects stored in the Vector? (And why Vector? That class has been
all but obsolete for ten years.) Do you count items referenced from those
objects? What of those indirectly referenced objects also live in other
structures or collections? Do you count the memory towards their usage as well?

What if the JIT compiler enregisters or puts some of that on the stack? What
if it inlines away some of the references altogether?

Don't forget to include the footprint of the monitors attached to the Vector
and each of its elements.

In short, there is no 100% reliably accurate way to measure the size of a
Vector as you describe the problem.

 

[Lew]

see http://mindprod.com/jgloss/sizeof.html

The size in bytes is known in Java. So you an compute with a
multiplication.

The size in bytes of what is known? The Vector itself? The elements it
contains? The references from those elements? Even in the face of JIT
optimizations like enregistering and inlining?

 

[Mark Space]

=) Mark, thank u for your help, but in context of my task i need to
know exactly the "length" in bytes, not memory allocation of byte[].
After some actions all data will be send to the some output stream anf

Andrea and Lew are both right. You basically have to do this yourself.
Even in C, you have some questions about what exactly you are going to
measure the size of. An array of pointers is likely to be much smaller
than the buffers it points to, but that would be the size of the array.
The buffers OTOH are probably what you want transmit, but if you used
a general memory counting algorithm, you'd likely have the size of the
array of pointers included.

It won't work as you imagine, in any language. An image of memory is
not dumped on the wire and then read by the other end. At least, I
think that would be incredibly hard to maintain.

You'll need to define the problem a bit better. Andrea's suggestion
isn't bad, especially if you have a disk you can spool to, or you're
sure that you can hold all your buffers in memory.

You might also try to send each object in the Vector separately. That
might be easier than trying to mash them all together first. HTTP does
this when sending pages. First the HTML is sent, then the images are
loaded one at a time. It's not one huge bundle.

Better yet would be to use a protocol that does not require you to know
the size before you send, but that may not be an option if you are
trying to send a single GIF or something. However, I'll mention that I
think using Java's serialization directly does do this--you don't need
the total number of bytes before you start sending. It might be an option.

Anyway, good luck. Let us know if you work it out.

 

[Nigel Wade]

=) Mark, thank u for your help, but in context of my task i need to
know exactly the "length" in bytes, not memory allocation of byte[].
After some actions all data will be send to the some output stream anf
to make correct blocks of data i need to know the subj. Anyway, thanx
for ur help.

Then what is important is how much data will be sent to the output stream, not
how much data is used internally. Even if you know, for example, that your
byte[] or Vector<T> occupies 36 bytes internally, it is almost certain that if
you stream that object to some output channel the resulting output won't be 36
bytes in length.

One way to perform such an operation is to serialize the object(s) to internal
memory, then see how much data has been streamed. That serialized data stream
can then be output, preceded by a byte count if the protocol requires it.

 

[Roedy Green]

The size in bytes of what is known? The Vector itself? The elements it
contains? The references from those elements? Even in the face of JIT
optimizations like enregistering and inlining?

I explain that at the URL.

 

[Lew]

I explain that at the URL.

Excellent!