1src Forums - View Single Post - CPU Cycles Killer on the TH55!

Fair enough. By the way, if you want far more detail you should go to this thread: http://www.1src.com/forums/showthread.php?t=62031.
Everything I am saying is just repeating what Igor_n taught me in that thread (it starts getting most interesting, i.e. technical, on page 3 of the thread).

So, the first principle is that what we are most concerned about is the load that an application is placing on the system in the background, i.e. even when it is not specifically invoked by the user. The way an application can burn cycles this way is by telling PalmOS that, even though it is not running in the foreground (i.e. it is not the application that the user is currently running), that it wants to be notified when certain events happen. If an application does this then every time that event occurs then some code within that application will be called so that it can check if it wants to respond to the event. Note that multiple applications can subscribe to the same event so there might be 10 applications called to effectively ask them "Do you want to do anything?" every time a hotsync event occurs (for example).

Some not-so-important events (performance wise) that an application might request notification for are soft reset, hotsync or an alarm going off. These are not so important because they occur relatively infrequently so if an app is burning an extra 0.1 seconds of CPU time every time a hotsync happens then that isn't really going to affect ongoing performance or battery life.

Probably the most important event performance-wise is the "hede" event. An application subscribing to the "hede" event is saying that it wants to be notified whenever any event happens in the system (button push, screen tap, etc). So the first thing to look at is look at the notification list and see which of your apps are subscribing to the hede event because those apps will have their notification code called pretty regularly during the running of the system. Look also at the help info in PalmInternals because Igor also references a couple of other event types apart from "hede" that will arise often during the running of the system.

So now that you have identified applications that have subscribed to often-occuring events in PalmOS, you now know that their notification code will be called frequently. Knowing this, the next issue becomes: what will be the CPU drain on the system every time this app is notified of a particular event?

Again, PalmInternals is your friend. There are a number of different ways in which an app can register with PalmOS for notification of an event, and some ways are more efficient than others. Look at the entry for each app under a particular event (e.g. "hede") in the notification list. If the entry for that app shows a string of the form "cbk <address>" then the app is using a reasonably efficient form of notification. If the app doesn't have such a string then it is probably using something called "sublaunch" notification, which means that the overhead is much higher.

So, the basic advise is to look for apps subscribed to "hede" and the other few events that Igor highlights, and particularly look at ones that aren't using <cbk> address notification, and those are probably the biggest "passive consumers" of CPU cycles.

Hope that helps.

- Julian

08-04-2004, 12:36 PM	#12
JulianL Registered User Join Date: May 2004 Location: London, UK Posts: 371	Fair enough. By the way, if you want far more detail you should go to this thread: http://www.1src.com/forums/showthread.php?t=62031. Everything I am saying is just repeating what Igor_n taught me in that thread (it starts getting most interesting, i.e. technical, on page 3 of the thread). So, the first principle is that what we are most concerned about is the load that an application is placing on the system in the background, i.e. even when it is not specifically invoked by the user. The way an application can burn cycles this way is by telling PalmOS that, even though it is not running in the foreground (i.e. it is not the application that the user is currently running), that it wants to be notified when certain events happen. If an application does this then every time that event occurs then some code within that application will be called so that it can check if it wants to respond to the event. Note that multiple applications can subscribe to the same event so there might be 10 applications called to effectively ask them "Do you want to do anything?" every time a hotsync event occurs (for example). Some not-so-important events (performance wise) that an application might request notification for are soft reset, hotsync or an alarm going off. These are not so important because they occur relatively infrequently so if an app is burning an extra 0.1 seconds of CPU time every time a hotsync happens then that isn't really going to affect ongoing performance or battery life. Probably the most important event performance-wise is the "hede" event. An application subscribing to the "hede" event is saying that it wants to be notified whenever any event happens in the system (button push, screen tap, etc). So the first thing to look at is look at the notification list and see which of your apps are subscribing to the hede event because those apps will have their notification code called pretty regularly during the running of the system. Look also at the help info in PalmInternals because Igor also references a couple of other event types apart from "hede" that will arise often during the running of the system. So now that you have identified applications that have subscribed to often-occuring events in PalmOS, you now know that their notification code will be called frequently. Knowing this, the next issue becomes: what will be the CPU drain on the system every time this app is notified of a particular event? Again, PalmInternals is your friend. There are a number of different ways in which an app can register with PalmOS for notification of an event, and some ways are more efficient than others. Look at the entry for each app under a particular event (e.g. "hede") in the notification list. If the entry for that app shows a string of the form "cbk <address>" then the app is using a reasonably efficient form of notification. If the app doesn't have such a string then it is probably using something called "sublaunch" notification, which means that the overhead is much higher. So, the basic advise is to look for apps subscribed to "hede" and the other few events that Igor highlights, and particularly look at ones that aren't using <cbk> address notification, and those are probably the biggest "passive consumers" of CPU cycles. Hope that helps. - Julian