4 ms·

Users don't distinguish between poor UI performance and"code stutters". The "negligble" sub-1ms stutters are a real problem in practice. and it's not just limit

by beatle 15y ago

Users don't distinguish between poor UI performance and"code stutters". The "negligble" sub-1ms stutters are a real problem in practice. and it's not just limited to poor code. Sometimes, no matter what you'll see GC being called, there's no way around it. There are background threads that are doing all sorts of things, which very well might be getting GC'd. Theres also a lot of things you can't reasonably avoid, like allocations from Iterators, etc. There are literally thousands of forum and blog posts discussing this online. Garbage Collection very slow on Android with latest stable line http://groups.google.com/group/v8-users/browse_thread/thread/bd3a269ff4107619 http://groups.google.com/group/v8-users/browse_thread/thread... How can I avoid garbage collection delays in Java games http://stackoverflow.com/questions/2484079/how-can-i-avoid-garbage-collection-delays-in-java-games-best-practices http://stackoverflow.com/questions/2484079/how-can-i-avoid-g... Avoiding garbage collection for smooth 2d animations Options http://groups.google.com/group/android-developers/browse_thread/thread/e342700f10e9f830 http://groups.google.com/group/android-developers/browse_thr... Image tiling on Android, garbage collector slows down http://stackoverflow.com/questions/7916021/image-tiling-on-android-garbage-collector-slows-down http://stackoverflow.com/questions/7916021/image-tiling-on-a...

babebridou 15y ago
Poor choice of words on my part. It's not "poor code" but "inadequate code". The Android graphics API is, overall, inadequate for avoiding GCs at all costs. Java on the other hand, is not necessarily inadequate. The issues with GC and the Bitmap class are a good example: Bitmaps aren't designed to work at the lowest & fastest level but at the highest and easiest level. Nothing beats primitives and buffers - the performance gap between the two methods is huge, that's true, but it's not a showstopper. I don't recall gcs in other processes hurting my apps performances though. With that said, if I'm going to write a game, I'll make sure none of the threads in my process will trigger a GC past the loading/splash screen. This means no instanciations of any additional iterators, collections, Strings... The overhead of allocations is almost as bad for the framerate as the GC anyway.

by beatle 15y ago

babebridou 15y ago

Poor choice of words on my part. It's not "poor code" but "inadequate code". The Android graphics API is, overall, inadequate for avoiding GCs at all costs. Java on the other hand, is not necessarily inadequate. The issues with GC and the Bitmap class are a good example: Bitmaps aren't designed to work at the lowest & fastest level but at the highest and easiest level. Nothing beats primitives and buffers - the performance gap between the two methods is huge, that's true, but it's not a showstopper. I don't recall gcs in other processes hurting my apps performances though. With that said, if I'm going to write a game, I'll make sure none of the threads in my process will trigger a GC past the loading/splash screen. This means no instanciations of any additional iterators, collections, Strings... The overhead of allocations is almost as bad for the framerate as the GC anyway.