[android-developers] Re: Performance issue executing native code on ICS
We met exactly the same issue! We are on ICS 4.0.4 with Nexus S. Will google plan to fix it in the next release say 4.0.5? Thanks, Chuan 在 2012年3月5日星期一UTC+8下午10时22分24秒，Michael写道： These are results of 'top' running the (unmodified) CameraPreview of the ApiDemos sample on two Nexus S devices, one with Gingerbread, the other one with Ice Cream Sandwich: 1) Nexus S, Gingerbread, Build Target: Android 2.3.3 User 1%, System 6%, IOW 0%, IRQ 0% User 6 + Nice 0 + Sys 21 + Idle 282 + IOW 0 + IRQ 0 + SIRQ 0 = 309 PID TID CPU% S VSS RSS PCY UID Thread Proc 1138 1138 3% R 1092K528K fg shelltop top 75 1142 1% D 32312K 4500K fg mediaCameraPreviewTh /system/bin/mediaserver 114 125 0% D 192872K 62016K fg system system_server system_server 182 182 0% S 103024K 27104K fg system ndroid.systemui com.android.systemui 114 126 0% S 192872K 62016K fg system SensorService system_server 2) Nexus S, ICS, Build Target: Android 2.3.3 User 28%, System 21%, IOW 0%, IRQ 0% User 90 + Nice 0 + Sys 69 + Idle 157 + IOW 0 + IRQ 0 + SIRQ 1 = 317 PID TID PR CPU% S VSS RSS PCY UID Thread Proc 81 2509 0 17% S 49372K 5100K fg mediaCameraPreviewTh /system/bin/mediaserver 78 131 0 15% S 39576K 17648K fg system SurfaceFlinger /system/bin/surfaceflinger 162 175 0 4% D 356748K 46212K fg system system_server system_server 2478 2478 0 3% R 1188K588K fg shelltop top 162 177 0 1% S 356748K 46212K fg system er.ServerThread system_server 3) Nexus S, ICS, Build Target: Android 4.0.3 User 44%, System 15%, IOW 0%, IRQ 0% User 140 + Nice 0 + Sys 50 + Idle 128 + IOW 0 + IRQ 0 + SIRQ 0 = 318 PID TID PR CPU% S VSS RSS PCY UID Thread Proc 81 2931 0 38% S 55904K 8412K fg mediaCameraPreviewTh /system/bin/mediaserver 78 131 0 7% S 45432K 22484K fg system SurfaceFlinger /system/bin/surfaceflinger 2921 2921 0 3% R 1188K588K fg shelltop top 162 175 0 2% D 356860K 47052K fg system system_server system_server 2718 2718 0 1% S 0K 0K fg root kworker/0:1 Indeed, one does not even need to perform any additional (native) processing to find that the mediaserver and surfaceflinger processes are consuming an unhealthy amount of CPU power on Ice Cream Sandwich. Note that the exact behavior even changes with different build targets; ~30% of CPU time are already bad when building against Android 2.3.3, but it gets a lot worse with ~45% when building against Android 4.0.3. Am planning to file a bug report. On Thursday, March 1, 2012 6:53:08 PM UTC+1, Chris Stratton wrote: On Thursday, March 1, 2012 12:08:31 PM UTC-5, Michael wrote: 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 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 mediaCameraPreviewTh /system/bin/mediaserver 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. You could try and see if you can get git to give up a diff of the relevant files in mediaserver between the two versions of Android, but that may be a lengthy path to follow. It would be interesting if you could reproduce the same difference in mediaserver CPU usage with someone else's code that doesn't do any (even dummy) native processing. Could you try the CamerPreview in the ApiDemos of the sdk samples? If you can reproduce the mediaserver CPU load reflected by top with that you'd clearly be in a position to file a bug report. -- 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
[android-developers] Re: Performance issue executing native code on ICS
These are results of 'top' running the (unmodified) CameraPreview of the ApiDemos sample on two Nexus S devices, one with Gingerbread, the other one with Ice Cream Sandwich: 1) Nexus S, Gingerbread, Build Target: Android 2.3.3 User 1%, System 6%, IOW 0%, IRQ 0% User 6 + Nice 0 + Sys 21 + Idle 282 + IOW 0 + IRQ 0 + SIRQ 0 = 309 PID TID CPU% S VSS RSS PCY UID Thread Proc 1138 1138 3% R 1092K528K fg shelltop top 75 1142 1% D 32312K 4500K fg mediaCameraPreviewTh /system/bin/mediaserver 114 125 0% D 192872K 62016K fg system system_server system_server 182 182 0% S 103024K 27104K fg system ndroid.systemui com.android.systemui 114 126 0% S 192872K 62016K fg system SensorService system_server 2) Nexus S, ICS, Build Target: Android 2.3.3 User 28%, System 21%, IOW 0%, IRQ 0% User 90 + Nice 0 + Sys 69 + Idle 157 + IOW 0 + IRQ 0 + SIRQ 1 = 317 PID TID PR CPU% S VSS RSS PCY UID Thread Proc 81 2509 0 17% S 49372K 5100K fg mediaCameraPreviewTh /system/bin/mediaserver 78 131 0 15% S 39576K 17648K fg system SurfaceFlinger /system/bin/surfaceflinger 162 175 0 4% D 356748K 46212K fg system system_server system_server 2478 2478 0 3% R 1188K588K fg shelltop top 162 177 0 1% S 356748K 46212K fg system er.ServerThread system_server 3) Nexus S, ICS, Build Target: Android 4.0.3 User 44%, System 15%, IOW 0%, IRQ 0% User 140 + Nice 0 + Sys 50 + Idle 128 + IOW 0 + IRQ 0 + SIRQ 0 = 318 PID TID PR CPU% S VSS RSS PCY UID Thread Proc 81 2931 0 38% S 55904K 8412K fg mediaCameraPreviewTh /system/bin/mediaserver 78 131 0 7% S 45432K 22484K fg system SurfaceFlinger /system/bin/surfaceflinger 2921 2921 0 3% R 1188K588K fg shelltop top 162 175 0 2% D 356860K 47052K fg system system_server system_server 2718 2718 0 1% S 0K 0K fg root kworker/0:1 Indeed, one does not even need to perform any additional (native) processing to find that the mediaserver and surfaceflinger processes are consuming an unhealthy amount of CPU power on Ice Cream Sandwich. Note that the exact behavior even changes with different build targets; ~30% of CPU time are already bad when building against Android 2.3.3, but it gets a lot worse with ~45% when building against Android 4.0.3. Am planning to file a bug report. On Thursday, March 1, 2012 6:53:08 PM UTC+1, Chris Stratton wrote: On Thursday, March 1, 2012 12:08:31 PM UTC-5, Michael wrote: 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 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 mediaCameraPreviewTh /system/bin/mediaserver 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. You could try and see if you can get git to give up a diff of the relevant files in mediaserver between the two versions of Android, but that may be a lengthy path to follow. It would be interesting if you could reproduce the same difference in mediaserver CPU usage with someone else's code that doesn't do any (even dummy) native processing. Could you try the CamerPreview in the ApiDemos of the sdk samples? If you can reproduce the mediaserver CPU load reflected by top with that you'd clearly be in a position to file a bug report. -- 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
[android-developers] Re: Performance issue executing native code on ICS
The corresponding bug report is filed here: https://code.google.com/p/android/issues/detail?id=26446 Michael On Monday, March 5, 2012 3:22:24 PM UTC+1, Michael wrote: These are results of 'top' running the (unmodified) CameraPreview of the ApiDemos sample on two Nexus S devices, one with Gingerbread, the other one with Ice Cream Sandwich: 1) Nexus S, Gingerbread, Build Target: Android 2.3.3 User 1%, System 6%, IOW 0%, IRQ 0% User 6 + Nice 0 + Sys 21 + Idle 282 + IOW 0 + IRQ 0 + SIRQ 0 = 309 PID TID CPU% S VSS RSS PCY UID Thread Proc 1138 1138 3% R 1092K528K fg shelltop top 75 1142 1% D 32312K 4500K fg mediaCameraPreviewTh /system/bin/mediaserver 114 125 0% D 192872K 62016K fg system system_server system_server 182 182 0% S 103024K 27104K fg system ndroid.systemui com.android.systemui 114 126 0% S 192872K 62016K fg system SensorService system_server 2) Nexus S, ICS, Build Target: Android 2.3.3 User 28%, System 21%, IOW 0%, IRQ 0% User 90 + Nice 0 + Sys 69 + Idle 157 + IOW 0 + IRQ 0 + SIRQ 1 = 317 PID TID PR CPU% S VSS RSS PCY UID Thread Proc 81 2509 0 17% S 49372K 5100K fg mediaCameraPreviewTh /system/bin/mediaserver 78 131 0 15% S 39576K 17648K fg system SurfaceFlinger /system/bin/surfaceflinger 162 175 0 4% D 356748K 46212K fg system system_server system_server 2478 2478 0 3% R 1188K588K fg shelltop top 162 177 0 1% S 356748K 46212K fg system er.ServerThread system_server 3) Nexus S, ICS, Build Target: Android 4.0.3 User 44%, System 15%, IOW 0%, IRQ 0% User 140 + Nice 0 + Sys 50 + Idle 128 + IOW 0 + IRQ 0 + SIRQ 0 = 318 PID TID PR CPU% S VSS RSS PCY UID Thread Proc 81 2931 0 38% S 55904K 8412K fg mediaCameraPreviewTh /system/bin/mediaserver 78 131 0 7% S 45432K 22484K fg system SurfaceFlinger /system/bin/surfaceflinger 2921 2921 0 3% R 1188K588K fg shelltop top 162 175 0 2% D 356860K 47052K fg system system_server system_server 2718 2718 0 1% S 0K 0K fg root kworker/0:1 Indeed, one does not even need to perform any additional (native) processing to find that the mediaserver and surfaceflinger processes are consuming an unhealthy amount of CPU power on Ice Cream Sandwich. Note that the exact behavior even changes with different build targets; ~30% of CPU time are already bad when building against Android 2.3.3, but it gets a lot worse with ~45% when building against Android 4.0.3. Am planning to file a bug report. On Thursday, March 1, 2012 6:53:08 PM UTC+1, Chris Stratton wrote: On Thursday, March 1, 2012 12:08:31 PM UTC-5, Michael wrote: 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 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 mediaCameraPreviewTh /system/bin/mediaserver 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. You could try and see if you can get git to give up a diff of the relevant files in mediaserver between the two versions of Android, but that may be a lengthy path to follow. It would be interesting if you could reproduce the same difference in mediaserver CPU usage with someone else's code that doesn't do any (even dummy) native processing. Could you try the CamerPreview in the ApiDemos of the sdk samples? If you can reproduce the mediaserver CPU load reflected by top with that you'd clearly be in a position to file a bug report. On Monday, March 5, 2012 3:22:24 PM UTC+1, Michael wrote: These are results of 'top' running the (unmodified) CameraPreview of the ApiDemos sample on two Nexus S devices, one with Gingerbread, the other one with Ice Cream Sandwich: 1) Nexus S, Gingerbread, Build Target: Android 2.3.3 User 1%, System 6%, IOW 0%, IRQ 0% User 6 +
[android-developers] Re: Performance issue executing native code on ICS
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 1076K512K fg shelltop top 75 783 1% S 34620K 5176K fg mediaCameraPreviewTh /system/bin/mediaserver 672 672 0% S 3416K184K fg shelladbd/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 mediaCameraPreviewTh /system/bin/mediaserver 78 131 0 3% S 40752K 20300K fg system SurfaceFlinger /system/bin/surfaceflinger 2878 2878 0 2% R 1172K572K fg shelltop 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
[android-developers] Re: Performance issue executing native code on ICS
On Thursday, March 1, 2012 12:08:31 PM UTC-5, Michael wrote: 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 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 mediaCameraPreviewTh /system/bin/mediaserver 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. You could try and see if you can get git to give up a diff of the relevant files in mediaserver between the two versions of Android, but that may be a lengthy path to follow. It would be interesting if you could reproduce the same difference in mediaserver CPU usage with someone else's code that doesn't do any (even dummy) native processing. Could you try the CamerPreview in the ApiDemos of the sdk samples? If you can reproduce the mediaserver CPU load reflected by top with that you'd clearly be in a position to file a bug report. -- 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
[android-developers] Re: Performance issue executing native code on ICS
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
