Good tip! This is a print from top running the test application on a Nexus S with Gingerbread:
User 89%, System 3%, IOW 0%, IRQ 0% User 282 + Nice 0 + Sys 12 + Idle 22 + IOW 0 + IRQ 0 + SIRQ 0 = 316 PID TID CPU% S VSS RSS PCY UID Thread Proc 771 771 86% R 104220K 27216K fg app_54 PerformanceTest com.ICSPerformanceTest 788 788 2% R 1076K 512K fg shell top top 75 783 1% S 34620K 5176K fg media CameraPreviewTh /system/bin/mediaserver 672 672 0% S 3416K 184K fg shell adbd /sbin/adbd 771 777 0% S 104220K 27216K fg app_54 Binder Thread # com.ICSPerformanceTest And this is the exact same application on a Nexus S with Ice Cream Sandwich: User 87%, System 9%, IOW 0%, IRQ 0% User 287 + Nice 0 + Sys 32 + Idle 9 + IOW 0 + IRQ 0 + SIRQ 0 = 328 PID TID PR CPU% S VSS RSS PCY UID Thread Proc 2849 2849 0 57% R 278568K 35372K fg app_66 PerformanceTest com.ICSPerformanceTest 81 2867 0 28% S 56408K 9196K fg media CameraPreviewTh /system/bin/mediaserver 78 131 0 3% S 40752K 20300K fg system SurfaceFlinger /system/bin/surfaceflinger 2878 2878 0 2% R 1172K 572K fg shell top top 153 166 0 1% D 353944K 45300K fg system system_server system_server For some reason, the CameraPreviewThread of the mediaserver process is using around 30% of processor time here. This does indeed explain the 'gaps' we are seeing, since this is native code being executed (and traceview doesn't display native threads). In our production code, the situation is even worse and the CameraPreviewThread can be taking up to 50% of CPU time on the Nexus S. This is a significant problem, as our processing then gets <40% of the available CPU time, as opposed to a device running Gingerbread where it gets >80%. We still don't know why this is happening, though. It's not an active face detection - we double-checked that. A quick look through the Android source code didn't give any insight either. Though my suspicion is that either something is wrong with the ICS implementation or the camera driver. It would be nice to get more info on that, and potential solutions to fix the issue. On Thursday, March 1, 2012 2:00:44 AM UTC+1, Chris Stratton wrote: > > On Wednesday, February 22, 2012 7:28:59 AM UTC-5, Michael wrote: >> >> When comparing method traces on this test project, we noticed a >> difference. On ICS we see lots of gaps in the execution of the native >> function call (i.e. in the JNI function call). On Gingerbread, these >> gaps are not present. >> We cannot explain why these gaps are there, since nothing else seems >> to be happening on other threads [that we can observe using >> traceview]. But they account for a large difference between the >> measured ‘excl real msec’ and ‘incl real msec’ on the ICS device. >> > > I think the most interesting question would be to figure out what is > happening during that time - something in another process, something in the > kernel, or something in a somehow invisible (?) thread in your process? > One contrasting tool your might throw at the problem would be top - ie > > adb shell 'top -t -m 5' > > Should show the top 5 five cpu-hogging threads system wide regardless of > the process they belong to. > > An interesting question would be what happens if you do the same > processing, but on data not derived from the camera, ie without activating > the camera. > > Perhaps something else is looking at the camera - is the platform trying > to do something fancy like software focusing, face recognition, scaling? > Is the new implementation broken? > > > On Thursday, March 1, 2012 2:00:44 AM UTC+1, Chris Stratton wrote: > > On Wednesday, February 22, 2012 7:28:59 AM UTC-5, Michael wrote: >> >> When comparing method traces on this test project, we noticed a >> difference. On ICS we see lots of gaps in the execution of the native >> function call (i.e. in the JNI function call). On Gingerbread, these >> gaps are not present. >> We cannot explain why these gaps are there, since nothing else seems >> to be happening on other threads [that we can observe using >> traceview]. But they account for a large difference between the >> measured ‘excl real msec’ and ‘incl real msec’ on the ICS device. >> > > I think the most interesting question would be to figure out what is > happening during that time - something in another process, something in the > kernel, or something in a somehow invisible (?) thread in your process? > One contrasting tool your might throw at the problem would be top - ie > > adb shell 'top -t -m 5' > > Should show the top 5 five cpu-hogging threads system wide regardless of > the process they belong to. > > An interesting question would be what happens if you do the same > processing, but on data not derived from the camera, ie without activating > the camera. > > Perhaps something else is looking at the camera - is the platform trying > to do something fancy like software focusing, face recognition, scaling? > Is the new implementation broken? > > > -- 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
