Wasn't that supposed to be a thing of the past with modern garbage collectors?
Wasn't that supposed to be a thing of the past with modern garbage collectors?
If I had to pick the single biggest annoyance with my android devices (which I otherwise love) then this would be it.
That's Moore's law for you.
I sometimes wonder how much more elegant our solutions to computing problems would become if transistors per integrated circuit stopped increasing exponentially.
It does seem likely that it is GC issues and not whether the GPU is used or not: The visual choppiness is completely inconsistent, lending itself more to brief thread stops for GCs than to any sort of CPU starvation.
On the bright side, it is far less common on 2.2 than before. It still is by no means a deal breaker, but pretty much every user of both the iPhone and Android makes note of the much more consistent smoothness of the former.
One thing that could be done in the meantime is to rewrite performance-sensitive Android UI code in a way that eliminates object allocation. In Java this would result in horrifying code, but it might be worth it, and they wouldn't necessarily have to use Java.
Hilariously enough, they started using V8 in 2.0 a year ago — so in 2.0 and 2.1, Javascript is JIT-ed but Java isn't!
1. GC is not run on some timer. So if a process is not allocating any memory and there is no low-memory situation then GC will never be fired irrespective of how long the application is running
2. The phone is never woken up by the CLR to run GC. GC is always in response to an active request OR allocation failure OR low memory notification.
3. In the same lines there is no GC thread or background GC on WP7
I would save judgement on Windows Mobile 7 until it really is running various apps and doing active day to day work. A fresh Android phone is very smooth. Once you have it checking all of your accounts, have twitter and facebook feeds and dropbox running, rdio in the background, etc, the demands on the GC are much higher.