seems like every month, Safari runs just a little bit slower on my
PowerBook. Some sites are worse then othersI cant visit cnn.com or newegg.com
without staring at the spinning beachball of death for 5 or 10 seconds.
Even worse, whenever this happens, Mail or NetNewsWire tend to go away
as well, rendering my system effectively useless. Clearly something was eating a bunch of CPU time, but there was no obvious way to tell what it was.
So, this afternoon I decided that Id bite the bullet and find the problem. I downloaded Apples CHUD toolset, installed it, and fired up Shark,
Apples system-wide profiling tool. I left it running in the
background, collecting performance data, while I loaded up a bunch of
slow websites, and then took a look at the profile that it generated.
The single biggest block of time was spent running
CFStringFindWithOptions (9.1%). Drilling down a bit, it looks like most
of those calls came from NSHTTPCookieDiskStorage (8.8% of the total).
So I fired up Safaris cookie editor and realized that I hadnt cleared
out my cookie cache since I first installed Safarithere were several
thousand cookies sitting there. From looking at the profile, Id guess
that OS Xs cookie system does a linear search through the whole cookie
jar every time it hits a page. Since the same basic code is used by
every native OS X application, thatd explain why both Safari and
NetNewsWire were slow.
I spent a few minutes cleaning out the cookie jar, andamazingly
enoughSafaris a lot faster. I havent seen the beachball of death
since I cleaned up the cookies; before I was seeing it every minute or
so. I dont have any hard benchmark numbers, but subjectively it feels
a lot better.
So, if Safaris running slow, try cleaning out your cookies.
Update: Thinking about it a bit more, it seems
obvious whats happeningevery single HTTP request does a linear read
of the cookie database. With some sites, a decent percentage of the
HTTP requests also result in a write to the cookie database.
Most likely, this triggers a reader-writer lock of the cookie DB, so
the write stalls waiting for a bunch of slow reads, and then a handful
of writes back up one after the other, so even if the cookie handling
is only eating 9% of the CPU, the total wall-clock time lost due to
locking could easily be really substantial. Even worse, this
effectively serializes HTTP requests, limiting the system to one
cookie-invoking request at a time. Thatd explain a lot of the weird
behavior that Ive seen in Safari, where one slow website will block a
dozen tabs from loading. Does anyone know if Tiger has a new cookie
implementation? Any decent database system will solve all of these problems.