Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!


Click here to return to the 'Reduce the CPU load from iTunes song encoding' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Reduce the CPU load from iTunes song encoding
Authored by: smithkennedy on Nov 24, '04 02:10:06PM

You may be getting the old Event Manager "event loop" confused with CFRunLoop / NSRunLoop, which are Mac OS X-only technologies, and exist at a very low level (CoreFoundation).

The Carbon Event Manager is a higher-level API for Carbon developers to use instead of the deprecated Event Manager API, and is usable either in Mac OS 8.6-9.2.2 if CarbonLib 1.1.1 is installed, or in Mac OS X. The Mac OS X implementation provides access to the underlying CFRunLoop using GetCFRunLoopFromEventLoop(). If you look at the documentation for the Carbon Event Manager, and also the discussion of "CFRunLoop" in CoreFoundation documentation, this should be come more clear.

I don't know specifics of thread management in Carbon apps on Mac OS X because I develop either to IOKit, POSIX, CoreFoundation APIs, or Cocoa APIs if I need to do a GUI for some reason (infrequent). But the fact that the CPU load is reduced when the Preferences dialog is open makes me think that iTunes creates a new Carbon Event Manager for that dialog, and since it is the front window, that thread gets the priority during its time slices. There is not a 1-to-1 relationship between CFRunLoops and Carbon Event Managers.

But when a new modal dialog for Preferences is presented by iTunes, the side effect of the underlying implementation seems to be that the CPU load drops by a third or so.



[ Reply to This | # ]