|
(There are updates for 9/21 and 9/22/05 that appear after the graphs and charts on this page. Don't miss them, because they help wrap this little project up...) Last Thursday I was running a compile of an open source package on a 933 MHz Macintosh G4 running Mac OS X 10.4.2 with all of Apple's latest patches and updates. The compilation seemed to be going more slowly than I expected, so I wondered if it was really using all of the available CPU. I brought up the Activity Monitor and saw THIS:
World Clock was consuming over 46% of my CPU?! That seemed very wrong to me, since World Clock does nothing more than display the current time somewhere on Earth. Why would it need 46% of my CPU to do that? I figured maybe the process had been corrupted by a power outage or some other problem. I used Activity Monitor to stop the process, which restarted itself automatically.
Resource usage immediately dropped to a more acceptable 8.10% as shown below:
Still, 8% of a 933 MHz CPU just to draw a clock still seemed excessive to me. I did some searches on Internet forums and found that others had noticed the CPU usage of World Clock on their systems. Most reported it being around 10%, though, which was a far cry from the 46.8% I had seen earlier. I wondered if what happened to me was just a fluke, so I checked in on World Clock an hour or so later. Here's what it looked like in Activity Monitor at that time:
World Clock had swallowed up another 1% of my CPU and almost a megabyte of RAM! That sure sounded like a memory leak to me, but I wanted to be sure of that before I "cried wolf". I coded a quick script to use the command-line "ps" utility to provide information about the 5 running Dashboard Widgets on my system (all from Apple's original OS X installation - nothing third party here) and write it to a file every hour. That way I could leave the Dashboard up as long as possible (like overnight when I'm not in the office) and see how the Widgets' resource consumption changed over time. I also wondered if this might not be a corrupted installation on the Mac I was using. I had a co-worker with a different model of Macintosh, but the same version of OS X installed differently (i.e., not a clone of mine), bring up Activity Monitor and the Dashboard. He left them going for a couple of hours and we checked on them later. Sure enough, he began seeing the same level of resource consumption. Other than being installed off the same original disc from Apple, these two systems were not the same, yet they exhibited the same resource problem. I figured I was on to something. Monday afternoon (around 12:41pm) I restarted the test machine, fired up Dashboard, and setup my monitoring script to take hourly snapshots. For the next few days (ending 4pm Thursday 9/22), I left the Dashboard up as much as I possibly could, including overnight and during the day. I imported the stats collected by my script into Microsoft Excel and created the following graphs of World Clock's resource usage. This first graph shows the total amount of CPU resources the widget consumed since it was activated. The point of this graph is to show relative CPU usage compared to the other Widgets examined, and to act as a check against the "snapshot CPU usage" numbers in a later chart (i.e., if the graph below showed minimal CPU usage, then the snapshot figures could be recording at a time when the Widget just happens to be most active, but if this graph shows a steady increase in CPU usage, we know that the activity levels are pretty constant). As you can see, the World Clock steadily consumed CPU resources all week, while its counterparts (the other Widgets tested) seemed to be sitting there quietly for the most part: 
The chart below shows "real" memory usage by the Dashboard Widgets. In this case, "real" memory is that contained on the chips attached to the Mac's motherboard. As you can see, World Clock pretty steadily consumed memory as it executed, while the other Widgets' resource demands remained pretty constant:
The graph below shows the Widgets' Virtual Memory usage. Virtual memory is stored on the hard disk in a file and swapped into and out of "real" memory as the information it contains is needed by the software. The more Virtual Memory a program uses (generally speaking) the more of a drain it places on the system and the slower it will tend to run. While World Clock wasn't as heavy a consumer of Virtual Memory as it was real memory, you can see that it did place a pretty steady demand on Virtual Memory as well:
 To give something of a feel for just how much of the CPU's capacity World Clock can consume, I took momentary snapshots of the percentage of CPU the Widgets were using at that time. World Clock's CPU usage was a little erratic from hour to hour, but it's clear that its CPU demands increase pretty quickly over a period of time. This is a bad thing because it means that less CPU time is available for other applications which might need it. (Fortunately, if the Dashboard is dismissed the drain on the CPU drops to near-zero.) 
(For those of you who want to look at the underlying data here more carefully on your own, click here to download a Zip file containing the Excel Spreadsheet I used to produce these graphs and (for those who don't have Excel) a CSV (comma-separated values) file that most other spreadsheets and software can use.)
Overall, the other Dashboard Widgets I was running (Address Book, Weather, Calendar, and Calculator) were quite well behaved. Their resource requirements were nearly zero even when they were being displayed on-screen. Those widgets occasionally need a few extra bytes here or there, but appear to release it when they're done with it. As a result, their plots on the graphs above show virtually no change in resource consumption over a 24-hour period. The same can't be said for World Clock. It starts consuming CPU the minute you bring it up. If you dismiss it from the screen (without quitting it), it stops consuming CPU cycles but holds on to its RAM. If you leave it up and it displays the time for long periods, it gradually consumes more and more CPU cycles and memory. If left on-screen for over 24 hours consecutively without termination, it will soon consume over 60% of the CPU while it's running. It Has Its Limits... Based on what I've observed here, CPU consumption appears to "top out" at around 80-85% on an ongoing basis. That means it's unlikely that World Clock will completely freeze the system. Its use of real memory appears to have topped out as well. It's held pretty steady at about 212MB for a while now. Again, this means it's unlikely to crash your system. Having said that, I think the fact that it drains as much CPU and RAM as it does implies that it could push a system "on the edge" to go over that edge and crash, lock up, or otherwise misbehave. Why Haven't I Noticed this Before? The reason some people might see a resource problem with World Clock and others wouldn't is dependent on two factors: the elapsed time that World Clock has been displaying the time since the Dashboard last launched it and the amount of system resources the user has to spare. If you regularly reboot or if you quit and re-launch the Dashboard (or World Clock) occasionally, you may never see a significant resource drain. If you only look at World Clock a few seconds at a time between reboots or re-launches of the Dashboard/Widget, you may never see a resource drain. But if you keep the system up for long periods of time and like to display the World Clock often, chances are you'll eventually see this issue creep up on you. The effect it will have on you will depend largely on how close you are to reaching your CPU and memory capacity apart from what World Clock is doing. If, for instance, you run a demanding application like PhotoShop and have "just enough" RAM to do what you do, this could put a real crimp in your work. For example, if PhotoShop is getting close to hitting the limit of the physical RAM in your machine and World Clock has sucked up 100MB or more, you might find PhotoShop crashing because it's run out of memory, or it may just run very slowly doing something that's worked fine in the past. In this case, you'd probably (incorrectly) assume that something is wrong with PhotoShop, when in fact the issue is that World Clock has sucked up the memory PhotoShop needed. Fixing the Problem I've dug through the JavaScript code of World Clock and have been unable to identify any bug that could cause the resource issues seen here. Then again, my JavaScript is rusty and I might now be seeing something obvious. What I can tell you is that the largest part of the resource consumption by World Clock is caused by the "sweep second hand" animation. That "wiggling" animation contributes about 85% of the CPU usage by World Clock and a big chunk of its memory consumption. By disabling the animation (but leaving the second-hand intact), I was able to reduce World Clock's CPU consumption from a 7-9% starting amount to a mere 1.1-1.3% starting amount. This also dramatically reduces its memory consumption as well, so it would take (I'm guessing) weeks or months to get to the kind of resource drain that the unmodified World Clock reaches in a couple of days. I placed the instructions for removing the "wiggling" animation of the second-hand in another article here. Next... Having finished this little project, I'm really curious to see why Safari seems to be chewing up a fair amount of CPU and RAM while it's just "sitting there" doing nothing. In any case, I hope you enjoyed this little investigation and found it informative, entertaining, or at least humorous. Please feel free to come back and visit this site anytime!
Related Blogs:
Related Links:
|
