Just use HTC desire and galaxy note for solve slow performance issue.
still, we shouldn’t have that much garbage collection.
This issue is a bit complicated it seems it has to do with how Android handles bytebuffers
Do you know where the allocations are happening or are you having trouble tracking it down? When I was doing memory allocation profiling in my app, I was using the allocation tracker in the ADT, which is really helpful, but it has the limitation that it only keeps track of the last 512 allocations (it uses a ring buffer), so its snapshot of allocations is really limited.
That wasn’t nearly enough, so I did a custom build of the kernel that increased the limit to I think 32K allocations instead of 512, and it gave me a complete picture of what’s going on.
Yes, it’s an incredible amount of effort to go through to do a complete OS build from source and flash it to the device to diagnose memory allocations in your app, but it was extremely helpful for me, and if you want to try it (probably as a last resort) I’ll help you get it set up.
As it turned out, most of the memory churn in my app was in allocating and recycling a lot of bitmaps to use as textures for jME quads (it pulls them off the network and displays them as you cruise around the app), and I was able to achieve a lot of benefit by creating an object pool for them instead of giving them back to the system for garbage collection when they weren’t being used. That, plus some other dedicated object pools for other large and frequently used objects, and I was able to eliminate the worst of GC pauses in my app. It does tons and tons of small allocations, but they don’t add up to a lot of bytes, so I concentrated on the big ones that would make it run out of memory and do a forced GC on alloc – those are the slow garbage collections that stop the world; the concurrent GCs that it does opportunistically in a side thread aren’t nearly as bad. The key is to leave enough memory free that it’s never forced to do GC to allocate an object, so don’t allow your app to allocate large quantities of memory in a short amount of time.
It’s lame that you have to work around Android’s poor garbage collection, but it’s the world we live in.
2 Likes
@sbarta said:
Yes, it's an incredible amount of effort to go through to do a complete OS build from source and flash it to the device to diagnose memory allocations in your app, but it was extremely helpful for me, and if you want to try it (probably as a last resort) I'll help you get it set up.
omfg, you're a warrior...
@sbarta said:
It's lame that you have to work around Android's poor garbage collection, but it's the world we live in.
hehehehhe
Actually the memory issue here is more with buffer writing when using bone animation.
Is this issue with gc only related to using bone animation?
@iwgeric said:
Is this issue with gc only related to using bone animation?
The issue with abnormal GC usage, yes.
Although jME3 still does allocations in the render loop from time to time, they are not that major to warrant rewriting those parts yet.
@Momoko_Fan said:
The issue with abnormal GC usage, yes.
Although jME3 still does allocations in the render loop from time to time, they are not that major to warrant rewriting those parts yet.
Not sure it's only bone animation, i noticed GC from time to time (not that much) but bone animation does increase the gc rate.