"
I've run across one you've probably seen before, but perhaps not "over analyzed" like this one...
I recently began seriously tinkering with OS X 10.4. I brought up the
Dashboard on a system, with 5 active widgets. I then was out of the
office a lot for a couple of weeks. When I came back, I started doing
some work on the machine (which hadn't been rebooted in the meantime).
The work I was doing seemed to be going a fair amount slower than I
expected it to, so I looked in Activity Monitor to see if I could
understand why. Sure enough, I found the answer.
The "World Clock" widget was consuming 46.8% of the CPU and over 150MB of real RAM. Ouch!
Figuring it was a fluke, I terminated the process and let it come back
up. That seemed to release the RAM and lower the CPU usage to around 8%.
An hour or so later, I checked again. Resource usage had increased.
Thinking maybe the machine was out of whack, I rebooted and started the Dashboard again.
As a double-check, I brought Activity Monitor and Dashboard (with the
same collection of Widgets) up on another machine that was built
entirely differently and was dual-CPU instead of single-CPU. Its
resource consumption started out in the 7-8% range. I left it going for
a couple of hours and, sure enough, it was using more CPU and RAM also.
I wondered if resource usage would continue unabated if World Clock was left on-screen 24 hours (or as much as possible, at least). I wrote a quick shell script to take an hourly snapshot of the Dashboard Widgets' resource usage and write it to a text file. That told quite a tale, even being just a couple of hours into the test.
Right now it's about 30 hours later in this experiment. World Clock is
up to 66.5% of the system's CPU, 99.42 MB of real RAM, and 241.11 MB of Virtual Memory. I am anticipating that by the time I return to the
office tomorrow it will have reached near 100% of the CPU and perhaps considerably more RAM. What I want to know is if this monster can bring down the entire system.
Since you're interested in Mac performance, you might want to have a
look at the article I've written, which I update as new information
becomes available to me:
OS X World Clock Widget Resource Problem
In any case, keep up the good work!
-Mike S.
(I replied to Mike that I'm not a fan of widgets, OS addons, etc. (never was even in the old days before OS X) - I prefer running lean so to speak (saves resources, cpu cycles and often less problems with os updates) I've seen some Tiger installs where users went "widget crazy" and turned even fast macs into snails.-Mike)
Same here. In OS 7/8/9 days I never went in for those little cutesy utilities that
changed the way your windows looked, animated your cursors, etc. All
that stuff is amusing for about 10 minutes and afterward it just eats up
resources.
I've been tinkering with the WorldClock.js script trying to see if I can
find where that memory leak is. I'm pretty sure it has to do with the
way the second-hand is drawn (and animated). If you disable the
second-hand animation, initial CPU usage drops from 7-9% down to about
1.2% and stays near that for a much longer time. Unfortunately, there
is still a "slow leak" memory wise, with every few ticks of the
second-hand adding a few K to the RAM in use. I suspect they aren't
destroying some JavaScript object when they're done with it. I just
haven't found which one it is for sure yet...
(he later wrote)
I have reported it to Apple through their web site. (in reply to the reader suggestion below)
I've also combed through the code enough to think this is a garbage
collection problem due to the way they wrote the code.
JavaScript apparently has a garbage collection methodology that says, in
essence, "if any object that references THIS object is still in memory,
I can't delete THIS object."
Based on what I can see in the source code, it looks something like
this:
Function A
Call function B
Call function C
Function B
Do something
Function C
Do something
Call Function A
So what we see is that when Function B is called, the JavaScript garbage
collector sees that A still has something to do, so it doesn't collect
the garbage for A yet. When B is done, it goes on to C. C does its
thing, then calls A to get the ball rolling again. Problem is, since C
never actually terminated, that keeps the original A and B "open" in
memory.
If you envision that the above functions are (in essence): Update the
current time (A), Draw the Hour/minute/second hands (B), and Make the
second hand wiggle (C)... You see the problem. Each second, the script
is effectively forcing the JavaScript interpreter to store the
last-second's state of function A, B, and C... along with the second
before that, and so on. Thus, the longer this thing is up and running,
the more "states" of A, B, and C it's storing. This requires more
memory, which requires more CPU to manage, which (combined together)
bogs down the system.
And since it's a "bogging down" that gets worse each time the
second-hand moves, the effects are dramatic if you keep the application
opened. If you just check it occasionally, only a few second-hand ticks
are displayed and thus only a few "states" are stored.
Thus, the only people who will ever notice this will be those who leave
their systems up over long periods of time (periodically checking the
World Clock) or those who don't leave their systems up for long periods
of time but who do leave the World Clock up a long time...
"
This reminded me of a problem Matthew reported with the "blued" task/process (hogging CPU cycles per activity monitor, which also reported some hangs IIRC). It's bluetooth related and didn't appear here on the only 10.4.2 install I have, but that machine has no bluetooth adapter installed. Matt said booting from the Tiger CD and running Disk Utility (repair the disk/RP) helped but not sure if the problem will re-appear over time.
A reader suggested he send a bug report to Apple (which he later said he's done)
FYI - a reader later sent a note that Apple's webkit blog noted
they're recently fixed over 4000 javascript memory leaks.
