Author
Topic: Huge RAM usage when rendering (Read 1634 times)

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.

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×540Tablet: 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?

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.

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.

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

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?

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.