Skip to content

String memory footprint on mobile (RAZR) and techniques to optimize it.

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.

technorati tags:

One Comment

  1. Vishal wrote:

    Its really amazing thing which should be known by all application programmer of J2ME

    Sunday, March 25, 2007 at 10:13 pm | Permalink

Post a Comment

You must be logged in to post a comment.