markusn82 wrote: > Mark Murphy, it doesn't sound like you were trying to be productive in > your original post.
Actually, I was. Still am, as a matter of fact. > Rather, I was trying to > make real suggestions for a real problem that exists. Likewise, mostly in the latter half of the post. > Despite all these efforts the game still ends up having spikes in its > FPS due to the garbage collector. When the GC executes from other > processes, it always takes up ~100-300 ms.. thats a deal breaker for a > real-time game. The ~100-300ms isn't that meaningful of a figure, though. Frame rate won't drop because of elapsed time of the foreign process' GC operation. Frame rate will drop if, during that time, too much CPU is utilized by GC, or access to some cross-process resource is blocked by GC, or something along those lines. Lacking any of that, it doesn't matter if a foreign process' GC takes 100ms or 100 minutes. I would watch the video that Mr. Nanek pointed out, but my ISP is having difficulty with some Google properties, YouTube among them, so my download rate is atrocious. However, from the slides and the snippet I've seen, the focus is on a game's own GC, not the GC from foreign processes. Multiple posts from Ms. Hackborn indicate that background processes' threads are in a background scheduling class that limits their CPU utilization. I am assuming that the frame rate effects you are seeing are severe, not just a 10% or so drop that might just be background process CPU time. So, I see the following possibilities: 1. That background scheduling class is not working in general. 2. That background scheduling class is not affecting GC operations (e.g., the GC thread is in the foreground class regardless of whether the process is foreground or background). 3. One process' GC locks some system resource that your game depends upon (which would shock the heck out of me). 4. The code generating the problematic GC is not in the background scheduling class (e.g., it called startForeground() and has an active Notification), though my understanding is that even this has a lower priority than the true foreground process. 5. It's not GC, but something else that is going on that coincides with the GC. If there are other possibilities that I have missed, please point them out. And, if you have already done this sort of testing and haven't mentioned the results yet, please do! Most of these should be testable theories. I'll be happy to run some tests, but I'm going to need some program that measures the impact of background processes on the foreground. I can cook up something, but it won't closely resemble a real-time game that heavily uses the NDK. This is what I was getting at in my second post -- in order to address this problem, we need some way to reproduce it and measure it. So, I'll poke at this some, but if somebody knows of an app (preferably with source) that uses 2D/3D graphics and logs its timestamped frame rates somewhere, that would be helpful, for me and for anyone else who might actually work on this problem. BTW, is there an open http://b.android.com issue on this? -- Mark Murphy (a Commons Guy) http://commonsware.com | http://twitter.com/commonsguy Android Training...At Your Office: http://commonsware.com/training -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
