It
seems like every month, Safari runs just a little bit slower on my
PowerBook. Some sites are worse then others—I can’t 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 I’d bite the bullet and find the problem. I downloaded Apple’s CHUD toolset, installed it, and fired up Shark,
Apple’s 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 Safari’s cookie editor and realized that I hadn’t cleared
out my cookie cache since I first installed Safari—there were several
thousand cookies sitting there. From looking at the profile, I’d guess
that OS X’s 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, that’d explain why both Safari and
NetNewsWire were slow.
I spent a few minutes cleaning out the cookie jar, and—amazingly
enough—Safari’s a lot faster. I haven’t seen the beachball of death
since I cleaned up the cookies; before I was seeing it every minute or
so. I don’t have any hard benchmark numbers, but subjectively it feels
a lot better.
So, if Safari’s running slow, try cleaning out your cookies.
Update: Thinking about it a bit more, it seems
obvious what’s happening—every 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. That’d explain a lot of the weird
behavior that I’ve 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.