We are currently working on the application that will have to receive XML. There is a potential problem here, that it is not always known how big the payload will be. The problematic outcome is, it will simply blow the memory.
Here are the results of method that creates new string object of incremental size and analyzes the memory on the RAZR v3.
String of size:0 uses 56 bytes of heap
String of size:1 uses 64 bytes of heap
String of size:2 uses 64 bytes of heap
String of size:3 uses 72 bytes of heap
String of size:4 uses 72 bytes of heap
String of size:5 uses 80 bytes of heap
String of size:6 uses 80 bytes of heap
String of size:7 uses 88 bytes of heap
String of size:8 uses 88 bytes of heap
String of size:9 uses 96 bytes of heap
String of size:10 uses 96 bytes of heap
String of size:11 uses 104 bytes of heap
String of size:12 uses 104 bytes of heap
String of size:13 uses 112 bytes of heap
String of size:14 uses 112 bytes of heap
String of size:15 uses 120 bytes of heap
String of size:16 uses 120 bytes of heap
String of size:17 uses 128 bytes of heap
String of size:18 uses 128 bytes of heap
So you can see that the pure overhead of String object is 54 bytes, that means that if you have a whole bunch of short String objects, there is a potential for memory optimization, especially it concerns the XML parsers.
So thanks to the colleague of mine, who pointed me to this old post on javaworld, authored by Vladimir Roubtsov.
One Comment
Its really amazing thing which should be known by all application programmer of J2ME
Post a Comment