I have been having problem with an app (which uses both java and C++ and OpenCV) which appears to be very inconsistent in the amount of time it takes to perform various tasks. To help diagnose this, I made a function in java (called one_off_speed_test()
) which did nothing but a series of integer maths problems in a loop that takes about half a second, and then prints the time taken to the log. If I call this function repeatedly from within onCreate()
then the time taken for each call is very consistent (+= 3%), but if I call it from within onCameraFrame()
, a function that OpenCV calls when it has an image ready from the camera, then the time taken for the maths test in each fram varies by anything up to a factor of two. I decided to try the execution sampler in eclipse/DDMS and see if I could work out what was happening. I saw that when I clicked on one_off_speed_test()
, it listed the parents and children of that function, along with a line saying "(context switch)". Then on that row, under a column labelled "Incl Real Time", it says "66%". Now I'm not very expert in using DDMS, and I only have a hazy idea about context switching, but from the description so far, does it look like I have a problem with context switching taking up a lot of time? Or am I misunderstanding the DDMS output.
Asked
Active
Viewed 2,255 times
9
1 Answers
2
Context switch describes the time spent to execute other threads. So, when your function is called from onCameraFrame()
, it shares CPU with other threads, not necessarily threads that belong to your app.
See also answers https://stackoverflow.com/a/10969757/192373, https://stackoverflow.com/a/17902682/192373
In the posted example, onCameraFrame()
spent 14.413665 sec on the wall clock, of which 4.814454 sec was used by one_off_speed_test()
(presumably, for 10 frames), and 9.596984 sec was spent waiting for other threads. This makes sense, because onCameraFrame()
callback competes for the CPU resource with the camera service, which runs in a separate system process.
-
Thank you for the info and the other links. But I'm still a little confused. Is the time of context switching (the 66%) the time taken to perform that other task in another thread, or is it more the overhead of the switching process itself? – Mick Jul 14 '14 at 13:53
-
My understanding is that it's time spent in other threads, not the time spent by the kernel to switch to other treads. – Alex Cohn Jul 14 '14 at 14:51
-
1The _term_ [Context switching](http://en.wikipedia.org/wiki/Context_switch) does not refer to the time spent in other threads, rather "the process of storing and restoring the state (context) of a process or thread so that execution can be resumed from the same point at a later time." As to what the execution sampler is _reporting_, I'm not sure. – Adam S Jul 14 '14 at 16:47
-
Looking at com/android/traceview/Call.java, context switch means only that MethodData.mId == -1, i.e. some method which id cannot be determined, e.g. belongs to other process. – Alex Cohn Jul 14 '14 at 19:25
-
1Context switching is expensive, but not THAT expensive. As undocumented as it seems to be, it has to mean the amount of time the thread was on the run queue but getting no CPU because of cost elsewhere. – David Sainty Jul 20 '14 at 23:27
-
What's the best way to debug what's happening during an Android Context Switch? I'm dealing with a case where looking up the user profile through a content resolver query is taking up to 18 seconds. I'm trying to find out what else is happening during this time: http://stackoverflow.com/questions/27794672/contactscontract-profile-taking-18-seconds-due-to-context-switch-usually-10-mil&r – brunobowden Jan 08 '15 at 20:08