NetNewsWire 2.1: Performance

When I started work on NetNewsWire 2.1, I had two main things in mind: NewsGator syncing and performance. I’ve talked a bit about syncing, so now I’ll talk about performance.

No silver bullet

Except in the simplest or most specialized applications, there is no “silver bullet,” one place to optimize your code that makes everything faster.

Imagine, for instance, a web browser with super-fast network but super-slow page layout.

Or imagine an email app with a super-fast database—but the text editor can’t keep up with your typing.

Fact is, performance issues are specific—usually even more specific than the above. For instance, the hypothetical text editor is slow only with HTML editing but not when editing plain text. And then, it’s slow only if you’re using multiple font sizes and have an embedded graphic.

So: there aren’t any silver bullets. Performance is a matter of reproducing the exact performance issues people run into, then making those specific things fast.

Sometimes there might be a silver bullet, sort of

Okay, there was one silver bullet, sort of, here: just producing a Universal binary made it faster on Intel Macs. But that’s it.

Shark!

So what I did was identify a few places where people were reporting performance bugs the most.

Then I used this super-cool tool from Apple called Shark.

Want to know what the heck is happening? Run Shark while it’s happening. (I find “Tree (Top-Down)” view most useful most of the time.)

Shark is utterly and totally my good friend.

Made some stuff faster

One thing I ended up having to do was rewrite almost completely the browser tabs manager. In 2.0 and 2.0.1, if you had a large list of browser tabs (in the hundreds), startup could take minutes, which is crazy.

In 2.1, a large list of browser tabs doesn’t affect startup time. (Oh, maybe a fraction of a second.) This was my top priority, and I was glad to nail it so completely.

(I go into more details about performance fixes in the change notes for 2.1b16.)

Made other stuff seem faster

There’s an art to performance fixes. Some stuff you make faster, other stuff you make seem faster.

Performance when marking all as read was one of those things. I was able to optimize it a little—but mainly it was bound by code that isn’t mine (SQLite code), so I couldn’t optimize it past a certain point.

How do you make it seem faster? The answer in this case was to use another thread, so that it doesn’t block the user interface. (When the user interface is blocked, that’s when you get the spinning beach ball.)

Problem solved. Now it seems instant.

My favorite couple posts

Avi Drissman wrote about NetNewsWire performance issues on his weblog a few weeks ago. I invited him to join the private beta, which he did.

And now he writes about how it’s “amazingly fast” and doesn’t lock up.

I love posts like that. You have no idea. That’s where my motivation comes from—making things people like. (Thanks, Avi!)