Speeding up Safari

Posted by Scott Laird Fri, 08 Apr 2005 00:58:31 GMT

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.

Tiger Update: It still uses ~/Library/Cookies/Cookies.plist–no SQLite. So it’s this is probably still a problem with Tiger.

Posted in  | Tags , , ,  | 12 comments

Comments

  1. nathan said about 16 hours later:

    What’s the deal with caching issues slowly choking Apple software? Did you see daringfireball.net/2005/03/fontcachesgone_wild ?

    Sloppy programming.

  2. Scott Laird said about 17 hours later:

    Yeah, I saw the bit on Daring Fireball. I cleaned out my font caches, but it didn’t help Safari any, and it’s unclear if it made logging in any faster–it takes me around 30 seconds to log in on my laptop. I’ll tackle that one on another day.

    I suspect that Apple’s using XML serialization and reader-writer locks all over the place for this sort of thing. That’s almost certainly what they’re doing with cookies (~/Library/Cookies/Cookies.plist makes that kind of clear). That’s fine for small sets of data that don’t change very often, but as the dataset grows and the amount of lock contention grows, it’s just a recipe for disaster.

    Since Tiger uses SQLite as the back end for Spotlight, I wouldn’t be surprised if Apple has started using it for other system databases, like the cookie list and the font cache. Hopefully we’ll know in a few weeks.

  3. Gavin Eadie said 1 day later:

    With ~1700 cookies in the cookiestore, the site:

    http://www.chron.com

      could spin the pizza for way over a minute !
    
  4. Dulcea said 1 day later:

    Firefox can be set to dump cookies on closing. Too bad someone at Apple didn’t think of that option.

  5. daniel said 1 day later:

    Actually, since cookies are isolated by domain, Safari really only needs to lock down cookies when two pages are open on the same domain. That might get rid of the multiple tabs beachball problem, but moving to SQLite would be a good thing all around anyway. I wonder if the same thing happens between windows, or just multiple tabs in the same window? That could be a leftover side-effect from hacking tabs into the existing system (remember, tabs were added late in development by popular demand).

  6. John said 2 days later:

    Another cache to clear is the icon cache.

    The folder ~/Library/Safari/Icons should be deleted periodically.

    The first time that I deleted it, I noticed a major speed improvement in safari’s start up time and general responsiveness.

  7. Scott Laird said 2 days later:

    Daniel: it’s not really a tab issue, because it even bites non-Safari apps that use the Cocoa HTTP libraries (like NetNewsWire). There’s only one cookie store, and the more things that you have accessing it, the more likely you are to have problems. So lots of windows vs. lots of tabs shouldn’t make any difference.

  8. Eric Longstaff said 7 days later:

    <blockquote>Another cache to clear is the icon cache. The folder ~/Library/Safari/Icons should be deleted periodically</blockquote>

    I’ve changed the permissions to that folder to ‘no access’ so it does not update the icons.

  9. Eric Longstaff said 7 days later:

    <blockquote>Another cache to clear is the icon cache. The folder ~/Library/Safari/Icons should be deleted periodically</blockquote>

    I’ve changed the permissions to that folder to ‘no access’ so it does not update the icons.

  10. Christina said 7 months later:

    I am having a problem with Safari and cookies. I can login to a site, but then when I try to go to another page on the site it tells me that cookies aren’t enabled. I then change the preferences in Safari and try again with the same error. The worst part is that it isn’t just Safari, it happens on Internet Explorer also. I have changed the preferences and security settings multiple times, but I cannot get it to work. HELP!!!!

  11. Norby said 9 months later:

    I have this problem frequently w/ Safari (and presumably it would happen with IE as well, if it uses the system-wide cookie cache in ~/Library/Cookies/Cookies.plist). Clearing all the cookies cleared things up (again).

    -/\/

  12. scott said about 1 year later:

    My safari was running unbearably slow as well. I tried clearing my cache, deleting cookies, resetting safari, but nothing worked. I finally unplugged my modem from the power source waited 30 sec and then plugged it back in. I then restarted my mac, launched safari and it was running as fast as ever.

Comments are disabled