That's a good idea. I will try that. On Thu, Feb 19, 2009 at 9:10 PM, Dianne Hackborn <hack...@android.com>wrote:
> Um yeah if you put a sleep and there are no other thread to run, you will > reduce CPU usage. This isn't really that useful a thing though. It just > means you are going to make your code run more slowly, for possibly no good > reason. When you lower the priority of your thread, it allows the kernel to > keep it running, unless there are higher priority threads that should run in > preference over it. > > Here's something you should try: just create a thread sitting there in an > infinite loop with a lower priority. How does it impact your UI? I would > guess that it won't. If that is the case, then there is something else your > actual background thread is doing that is causing the problem. > > > On Thu, Feb 19, 2009 at 11:59 AM, Mariano Kamp <mariano.k...@gmail.com>wrote: > >> Also changing the prio to >> THREAD_PRIORITY_LOWEST<http://developer.android.com/reference/android/os/Process.html#THREAD_PRIORITY_LOWEST>didn't >> help things either. >> >> During the part where I use an XML pull parser to get through the input >> document I added SystemClock.sleep(20) when getting a START_TAG event. >> >> I attached screenshots for the version without the sleep (0ms.png, a >> little bit of a misnomer as there was no sleep at all, not even 0 ms) and >> 20ms.png for the above mentioned sleep. They both did kind of the same work >> (ignore the MB), but the 0ms was much faster, but the CPU was pretty much at >> the limit during that time. The 20ms version ran longer, but kept the CPU >> below 50%. >> >> 2009/2/19 Mariano Kamp <mariano.k...@gmail.com> >> >> I can see that. I just don't know how to proceed from here. I don't wont >>> to water down the problem description with lots of details of my app, but as >>> it is not a problem I know how to describe on an abstract level I will still >>> try do that in the briefest form I see fit. >>> >>> Maybe my "measurement" is wrong. I have a list row that represents an >>> article from Google Reader. If I swipe over it from left to right, it is >>> marked as read. As, depending on the system's load, this might take a moment >>> I change the background of the list row to a shade of yellow to give a >>> visual indication that the gesture is recognized, then go to the sqlite3 >>> database change the state of the article to read and fire a model updated >>> event that triggers a notifyDataSetChanged() on the List Adapter. That will >>> at some point call BaseAdapter.getView() ... In that method I then display >>> the changed representation (article title is not bold anymore then) and >>> reset the background color of the list row to the default again. So for the >>> duration of the foreground activity (updating the article and reflecting >>> that on the UI, see before) the background is yellow. >>> >>> Ok, now the guesstimeasurement I do is that I look at the time the >>> background is yellow. This time is very brief, when the background thread is >>> not running and went to 4 seconds when the background thread is running and >>> half of that when the background thread is running with the background prio. >>> >>> Maybe that is already what can be achieved? I was expecting that the >>> foreground activity (the db update etc.) with a running background activity >>> would be almost as fast as without a background activity when using the low >>> prio. >>> >>> 2009/2/19 Dianne Hackborn <hack...@android.com> >>> >>> I am surprised by that. Note that all of the stuff we do in the >>>> background on the system (synchronizing data and updating databases and >>>> such) is just done with normal threads, running at background priority, >>>> doing nothing fancy, and this has little impact on the UI. You really >>>> shouldn't have to play fancy games to get the kernel's scheduler to run one >>>> thread over another; that's exactly what the scheduler and its thread >>>> priorities are for. >>>> >>>> >>>> On Wed, Feb 18, 2009 at 12:15 PM, Mariano Kamp >>>> <mariano.k...@gmail.com>wrote: >>>> >>>>> Thanks for the quick answer. >>>>> >>>>> That helped, a lot. Not quite fantastic yet though. >>>>> >>>>> No background activity: < 300ms (gesture starts something, until >>>>> something ends) >>>>> With background activity, before 3500ms >>>>> With background activity, after 1500ms >>>>> (All numbers are just guesstimeasured for illustration purposes...) >>>>> >>>>> Anything else I can do? ;-) >>>>> >>>>> >>>>> 2009/2/18 Romain Guy <romain...@google.com> >>>>> >>>>> >>>>>> The proper way to set your thread priority is to execute the following >>>>>> line *in run() method of the thread*: >>>>>> >>>>>> Process.setThreadPriority(Process.THREAD_PRIORITY_BACKGROUND) >>>>>> >>>>>> On Wed, Feb 18, 2009 at 11:32 AM, Mariano Kamp < >>>>>> mariano.k...@gmail.com> wrote: >>>>>> > Hi, >>>>>> > >>>>>> > I wrote an app that acts as a Google Reader client. It downloads >>>>>> an XML >>>>>> > from Google, parses it and afterward analyzes web pages with regular >>>>>> > expressions to find image and stylesheet tags to make the pages >>>>>> available >>>>>> > offline. >>>>>> > >>>>>> > So far so good. The problem is the above mentioned tasks are >>>>>> pretty CPU >>>>>> > intensive and I also use gesture to mark items as read etc. The >>>>>> gesture >>>>>> > detection gets really bad when done during the synchronization phase >>>>>> (see >>>>>> > above). >>>>>> > >>>>>> > Those tasks from the synchronization phase are not time critical. >>>>>> I would >>>>>> > like to tell the OS that the UI thread is far more important than my >>>>>> > background thread. I just don't know how to do that efficiently. >>>>>> > >>>>>> > In an ideal world the OS would take care of that for me, so I >>>>>> started out >>>>>> > with "Thread.currentThread().setPriority(Thread.MIN_PRIORITY);". >>>>>> That didn't >>>>>> > have any obvious effect. Then I sprinkled "Thread.yield()" in all >>>>>> major >>>>>> > areas, in particular in the loops. But that also didn't seem to have >>>>>> much of >>>>>> > an effect. Before I know start to to all kind of silly stuff, I'd >>>>>> like to >>>>>> > pick your brains on how this is done properly? >>>>>> > >>>>>> > I am absolutely willing to use Thread.sleep(20) in some of the >>>>>> places I use >>>>>> > Thread.yield. A little bit of a pause might be a good thing for the >>>>>> battery >>>>>> > heat and power consumption, but I can't let the pause get really >>>>>> long, e.g. >>>>>> > 250ms, because I wouldn't get any work done and would keep the phone >>>>>> awake >>>>>> > unnecessarily (I am holding a partial wake lock). On the other hand >>>>>> I am not >>>>>> > sure if a small pause now and then, like a 20ms pause, then 50ms >>>>>> work, won't >>>>>> > take too much a toll on the CPU for switching tasks and in the end >>>>>> burn the >>>>>> > battery too fast. >>>>>> > Also, what seems like a good pause for the G1 might be not so much >>>>>> of a good >>>>>> > idea on different hardware, like a Netbook. >>>>>> > >>>>>> > I could try to set the Priority of the UI thread to MAX_PRIORITY, >>>>>> but as I >>>>>> > didn't start the thread, I feel that it's not my business to change >>>>>> its >>>>>> > priority. >>>>>> > >>>>>> > I could check if the screen is off. If that is the case high >>>>>> resolution >>>>>> > touch events are not so likely so I could revert all the measurement >>>>>> from >>>>>> > above until the screen comes on again. >>>>>> > >>>>>> > So what do you think? I guess I am not the only one with the >>>>>> problem, or >>>>>> > am I? >>>>>> > >>>>>> > Cheers, >>>>>> > Mariano >>>>>> > >>>>>> > > >>>>>> > >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Romain Guy >>>>>> Android framework engineer >>>>>> romain...@android.com >>>>>> >>>>>> Note: please don't send private questions to me, as I don't have time >>>>>> to provide private support. All such questions should be posted on >>>>>> public forums, where I and others can see and answer them >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Dianne Hackborn >>>> Android framework engineer >>>> hack...@android.com >>>> >>>> >>>> Note: please don't send private questions to me, as I don't have time to >>>> provide private support. All such questions should be posted on public >>>> forums, where I and others can see and answer them. >>>> >>>> >>>> >>>> >>> >> >> >> > > > -- > Dianne Hackborn > Android framework engineer > hack...@android.com > > Note: please don't send private questions to me, as I don't have time to > provide private support. All such questions should be posted on public > forums, where I and others can see and answer them. > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
