Object size in memory

[caraiz]

Im testing how much memory is an object in memory, and i trying the next in wtk1.0.4....

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18

public class Rectangle { } public class RectangleB {     public byte x,y,width,height; } public class RectangleI {     public int x,y,width,height; } public class RectangleL {     public long x,y,width,height; }

The class Rectangle is 12 bytes, the RectangleB and RectangleI is 28 bytes and RectangleL is 44.

I would like optimize memory size using RectangleB instead RectangleI, but its the same size.....
Anybody knows why RectangleB and RectangleI have the same size? its cause emulator or also its at real mobile?

Thanks

[larry]

What did you use to measure the memory?

[caraiz]

What did you use to measure the memory?

memory monitor of wtk1.04 and wtk2.0

Games published by our own members! Check 'em out!

[oNyx]

>Anybody knows why RectangleB and RectangleI have the same size?
>its cause emulator or also its at real mobile?

I could guess it... the entry points in ram aren't byte accurate. Think about it like clusters, wich are usually about 4k... it doesnt matter if you use 1 byte or 4096 bytes it's always one "full" cluster.

I've seen that several times in C programs too... a struct with "fillers" to align the struct.

[cfmdobbie]

Yep, your hardware is using 32-bit words.  It is (generally) a lot faster to store and retrieve data on word boundaries, so either Java or the underlying implementation is putting the 8-bit bytes into individual 32-bit memory locations.

Ints happen to be 32-bits already, so they fit nicely on word boundaries.

[larry]

yep, that seems to be the reason.

A simple "hack" to save memory would be to use ints
and treat them as a byte array[2] using byte masks and bit
logic.

Larry

[oNyx]

A simple "hack" to save memory would be to use ints
and treat them as a byte array[2] using byte masks and bit logic.

That's usually not worth the pain. The additional logic, wich is required, eats some bytes too and compression ratio can turn from "awesome" into "not exsistent".

For example... I had a level file like that:

1   2   3

11111111111111111111 10000000000000000001 10000000000000000001 10000000000000000001 10000000000000000001 10000000000000000001 10000000000000000001 10000000000000000001 10000000000000000001 [values ranging from 0-7] [...]

6300 bytes in size... it compresses down to 638 bytes. The same binary encoded (with 3 or 4 bits) wouldn't be significantly smaller after compression and the overall size (together with the required logic to decode it) will be slightly bigger than before.

Alot of work and it doesnt even save a single byte... also it took even longer to load lol

[shareme]

Im testing how much memory is an object in memory, and i trying the next in wtk1.0.4....

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18

public class Rectangle { } public class RectangleB {     public byte x,y,width,height; } public class RectangleI {     public int x,y,width,height; } public class RectangleL {     public long x,y,width,height; }

The class Rectangle is 12 bytes, the RectangleB and RectangleI is 28 bytes and RectangleL is 44.

I would like optimize memory size using RectangleB instead RectangleI, but its the same size.....
Anybody knows why RectangleB and RectangleI have the same size? its cause emulator or also its at real mobile?

Thanks

It relates to how int, byte and long are defined bitwise in JVMs..

Since you never goign to see long in J2ME why the question?

[larry]

That's usually not worth the pain. The additional logic, wich is required, eats some bytes too and compression ratio can turn from "awesome" into "not exsistent".

very worthy point!

[Abuse]

Since you never goign to see long in J2ME why the question?

?