Huge RAM usage when rendering

Started by K24A3, November 27, 2011, 04:07:06 AM

Previous topic - Next topic

K24A3

I'm seeing a huge difference between the RAM usage on a phone and a tablet. My project only uses 16MB/32MB on the phone, but 45MB/48MB on the Tablet. The Tablet intermittently throws an out of memory exception when rendering. (I'm using jPCT 1.24)


To rule out a bug in my project, I created a test app with 50 spheres using no texture. I clone 49 spheres from the first sphere.

In the test app, the Tablet is using 20MB compared to 9MB on the phone.


PowerVR Omap4430 Gingerbread 2.3.5 phone:
- 6MB/32MB after loading textures
- 8MB/32MB after calling world.buildallobjects()
- 9MB/32MB when rendering

Tegra2 Honeycomb 3.1 Tablet:
- 8MB/48MB after loading textures
- 9MB/48MB after calling world.buildallobjects()
- 20MB/48MB when rendering

I tried MemoryHelper.compact(), mesh.compress(), but it made little difference.
I tried using Primitives.getSphere() on all 50 objects instead of using clone(), but that only increased the usage by one or two MB.

I doubt it's a screen resolution problem because they are not much different.
Phone: 960×540
Tablet: 1280x800

I doubt there is a memory leak, the RAM usage is generally consistent after 20 minutes.

I can't figure out why so much RAM is used. Perhaps the Tegra2 OpenGL driver is inefficient? Or is jPCT loading extra poly/vertex information on the Tablet?


Attached are the logs and main class.


[attachment deleted by admin]

EgonOlsen

#1
jPCT-AE itself has no influence on this. It doesn't change anything based on the platform it's running on. It isn't even aware of it. I've no explanation for this behavior. It would be interesting to see WHAT exactly consumes the memory.

K24A3

It would be very interesting indeed. I'll have a look if there are any heap debugging functions in Android and try an Omap Tablet running 3.2.
I'm guessing it's an inefficiency in 3.1 or a Tegra2 driver/design issue.

K24A3

The high RAM usage is also happening on an Omap 4430 PowerVR Tablet running Android 3.2, which happens to be the exact same CPU/GPU as the Phone.

I used the Eclipse Memory Analyzer to view the object sizes. Object3D is using the most RAM which is no surprise, but the Object3D RAM usage is double on the Tablet which is strange. The byte[] array count is also a concern. 418K on the phone, 10MB on the tablet :O

The same APK was used on both devices.


[ PHONE ]
Class Name              | Objects | Shallow Heap | Retained Heap
-----------------------------------------------------------------
com.threed.jpct.Object3D|      79 |       28,440 |  >= 5,656,544
byte[]    |   2,483 |      418,152 |    >= 418,152
-----------------------------------------------------------------





[ TABLET ]
Class Name              | Objects | Shallow Heap | Retained Heap
-----------------------------------------------------------------
com.threed.jpct.Object3D|      79 |       28,440 | >= 11,867,800
byte[]    |   3,214 |   10,232,480 | >= 10,232,480




I attached a comparison of the objects that are using the most RAM.

I'm thinking it's a Honeycomb issue in relation to memory mapping or object management.




[attachment deleted by admin]

EgonOlsen

You might have to trigger a garbage collection before taking this values. At least on the desktop with VisualVM, this has a large impact. The fact that something is still in ram doesn't mean that it isn't actually a garbage collection victim. Everything else doesn't make any sense...why should 79 Object3Ds consume twice the memory on Android 3.x?

K24A3

Those values are with the garbage collector triggered, you have to do that anyway to get the heap dump file. I have the RAM usage displayed on the Android device and DDMS, there is almost no difference before and after (most I saw was ~20KB difference).

Honeycomb introduced the large heap size which gives you the option to increase the RAM limit per app to 256MB so perhaps google decided to do some major heap restructuring to take advantage of the increased RAM. Invisible free space to accommodate object growth and minimize GC pauses perhaps?

The large heap option in the manifest isn't available in Gingerbread and earlier so I guess I'll just need to create a separate APK for Tablets.