inessential by Brent Simmons

November 2007

ZoneMonitor, Mystery Tool

If you look at /Developer/Applications/Utilities/ZoneMonitor.app, you’ll find a garbage collection debugging tool. Apple’s documentation refers to it as an “application for analyzing memory usage” but doesn’t say any more.

I had to launch it twice—the first time it crashed. I don’t know if that was a fluke or not (could have been). On second launch I pointed it at a little demo garbage-collected app, and it launched collected and non-collected versions and compared them. I double-clicked on auto_zone, and got a new window with tabs for Heap and Roots. Etc. It’s explorable—I don’t know what it all means yet, but it’s intriguing.

Shark, my good friend

I’m sure I’ve said before how much I love Shark. (Shark, for those who don’t know, is Apple’s awesome tool for figuring out performance problems.)

Here’s the thing: it seemed like the Combined View in the latest NetNewsWire betas was faster on Tiger than on Leopard. I would have expected the other way around, of course, as Apple tends to make new operating systems feel like hardware upgrades.

So I ran the app using Shark to see what the problem was.

I found that 37.7% of the time in the main thread was spent in -[WebView(WebPrivate) _preferencesChangedNotification:]. That seemed really suspicious. (It totally didn’t match any of my theories—but the beauty of Shark is that it tells you where the slow-down is, no matter what your theories are.)

Your first guess may be that it’s a WebKit bug, since it appears in WebKit code. But it’s not. _preferencesChangedNotification does a bunch of preferences look-ups—it uses NSUserDefaults to look up a bunch of values. The slow-down is looking up the values.

To get a comparison, I did the same thing on a machine running Tiger—an older, slower machine, actually—and found that it spent just 15.6% of its time in _preferencesChangedNotification.

Holy farts! Shark rules.

Then I created a little command-line app that would tell me how long it takes to do a bunch of preferences look-ups. To get a fair comparison, I ran the app on a dual-boot machine.

The code calls CFPreferencesGetAppBooleanValue 100,000 times to read a pref from Safari’s preferences.

Results:

Leopard (10.5.1): 2.10 seconds

Tiger (10.4.11): 0.06 seconds

You can download the project if you want to. The bug has been filed with Apple as rdar://5608561.

Feed Overload? Hit the Panic Button!

Nick Bradbury: “The ‘panic button’ in this case is a feature I’ve added to the next pre-release of FeedDemon 2.6. FeedDemon will automatically detect when you’ve got a ton of unread items, and then offer to mark them (or a subset of them) as read.”

Great feature idea—I’ll probably lift it for NetNewsWire. (It won’t make it into 3.1, but hopefully the release after that.)

NetNewsWire Lite 3.1b1 public beta

I just posted a public beta of NetNewsWire Lite—Lite 3.1b1 is on the betas page.

For anyone who doesn’t know: NetNewsWire Lite is NetNewsWire’s freeware older brother. (Lite 1.0 shipped a few months before NetNewsWire 1.0.)

The Lite version is missing all kinds of cool features—searching, the built-in tabbed browser, flagging items, scripting, and so on—and yet I have a huge soft spot for it. I think it’s a pretty cool app.

A few screenshots—click for the big version:

Default style screenshot nnw - gray style screenshot nnw style screenshot

The most important thing about this release is, of course, that it fixes a couple Leopard incompatibilities. (There are none remaining that I know of.)

New to the Lite version are a couple features the full version has had for a long time: a Date column (which you can sort by), and a Dinosaurs report, so you can see which feeds haven’t updated in a long time.

Big damn icons

An article on Macworld reminded me that Leopard can use really big icons for applications.

I remembered that I had a super-large version of the NetNewsWire app icon, and so I could easily add 512 and 256 representations. Well, easily, maybe—as long as the process itself is easy.

Turns out it was. I just launched /Developer/Applications/Utilities/Icon Composer.app, did a couple drag-and-drops from the Finder, and I was finished. So the next beta will include 512 and 256 versions of the icon.

Here’s a screenshot of the big icon in the Finder’s cover-flow view.

Fraser on Twitterrific 3

Fraser Speirs writes about Twitterrific 3.0, which now displays ads or costs $14.95 (you choose):

Let’s face it—if you’re an indie Mac developer, Twitter is like a year round WWDC doughnut stand. It’s where I hang out with the other indies for the other fifty-one weeks of the year. If an easy interface to that world isn’t worth $15 to me, then I’ve got some messed up priorities.

The list of people I follow on Twitter is a lot like a listing of my /Applications folder, and it’s also a list of people I hang out with at events like C4 and WWDC.

It may be especially cool for people like me who work at home—it’s my virtual office.

But, were it not for Twitterrific, I probably wouldn’t have even tried it at all.

Rounded corners and shadows on new WebKit

I wasn’t planning on redesigning my weblog—but then I was recently reminded that you can do shadows and rounded corners using new CSS bits in the latest WebKit.

-webkit-box-shadow creates shadows. -webkit-border-radius creates rounded corners.

If you’re running Safari on Leopard (or probably any Safari 3 beta, or app that uses that same version of WebKit), and you’re on the home page of this site, you’ll see that each day has rounded corners at the top right and left and that each day casts a shadow. The page container also casts a shadow on the background graphic. And there’s a small shadow below the navigation links.

I’ve always went blech at the tricks people had to use to get rounded corners and shadows—hacks with images. Being able to do it with simple CSS is cool.

One thing I still want is gradients. The background at the top of this box should be a gradient. But it looks like I have to use an image for that. (Please correct me if I’m wrong!)