I was recently talking with a friend who is thinking of replacing his beloved but aging eMac 700 with something modern, and was trying to help him work out what the smart buy for his usage would be. His current complaint was that he gets the spinning beachball in Safari an awful lot and the entire system seemed sluggish when he had several browser windows open. I got him to run Activity Monitor to examine whether Safari’s cache problems were contributing to the slowness. One of the things he mentioned that startled me was that iTunes on his machine was taking a steady 25% of the CPU time.
I was surprised because on my daily machine, I’ve never seen its usage vary much from around 10-11%. Then I compared my machine’s CPU (a 1.67 GHz G4) with his (a 700 MHz G4) and realized that the amount of work being done by both machines was similar, and because his CPU was about half as fast as mine, it was having to do twice as much work as mine in the same time to play back the MP3 file. iTunes doesn’t have the option to do the same work at the same rate over twice as long a time, of course, because then your MP3 music would play back at different speeds depending on how fast a processor iTunes was running on.
I was curious to know exactly what iTunes was doing with the CPU cycles it was consuming, so I opened Activity Monitor on my PowerBook while iTunes was running, and found the iTunes process in the list. I clicked Inspect to bring up the detailed view of the iTunes process, and then clicked Sample. What this does is ‘trace’ all the system calls made by an application while it’s running, so you can see exactly what it’s doing at any time. The output it produces is shown in the image (left). The more you know about Mac OS and Mac programming, the more it’ll mean to you, but it’s not hard to figure out the very basics of what an app is doing whatever your background.
I ran a few traces on iTunes as it was playing music, and I was surprised to see that in every sample there was just as much work being done in graphics calls as in the actual reading, decoding and playing of music. You can see some of the graphics related work highlighted in the trace sample. Everyone who uses iTunes will have noticed the smart-looking LCD-style display at top and center, which mimics the screen of a G3 iPod and shows the current song information. There’s a progress bar showing the playing position of the current song, and if the song name is wider than the display, the text of the name scrolls right to left. It seems animating this display is quite expensive in terms of CPU power.
In order to help my friend with the eMac, I mused, it would be nice if we could do without the graphical work that’s draining his processor. The easiest way to do this is to run iTunes without a window. This won’t be intuitive to current or recent Windows users (and sadly, the facility isn’t available to Windows iTunes users), but the vast majority of Mac apps can manage quite nicely without any open windows. On Windows, however, when you close all an application’s windows, the application quits. Back on the Mac, though, you can give iTunes a list of tunes to play, press the Play button and then close the iTunes window, and iTunes will happily play through your list of music whilst remaining ‘invisible’.
So I started iTunes playing and closed its window, and checked Activity Monitor to see what it was now doing. Sure enough, the graphics calls disappeared from the Sample trace, and the CPU utilization dropped by about half, so that on my PowerBook it went from 11% CPU to around 3.8%. Hiding the application produced about the same result, and minimizing it to the Dock used slightly more CPU, at 4.4%. I was mildly surprised by the last result, because Dock icons are ‘live’ to some degree, and I’d expected iTunes to still try to draw a miniature version of the LCD display. I reasoned that if the icon is so small you can’t see the display, iTunes will not try to draw anything too complex.
I repeated the test on my 1.6 GHz Core Duo Mac Mini, which has the equivalent of two 1.66 GHz CPUs, and the total CPU load was 3.9% when iTunes’ window was visible, but only went down to 3.0% when it was closed or hidden. The comparison between G4 machines is sort of meaningful, but comparing across machine and processor architectures, and instruction sets isn’t very useful; all that I took from the last test was that there’s minimal benefit in hiding iTunes on an Intel Mac Mini.
I’m glad to say that by hiding iTunes, my friend reduced the CPU load due to iTunes from 25% to 8%. So, if you have an older Mac and you’re seeing it begin to struggle while playing music, just hide iTunes and grab some cycles back.
Technorati Tags: Profiling, iTunes, Old Macs, Trace, Sampling, OS X, Macintosh, CPU, Software, Tiger
Comments