We’re gonna need a bigger boat. (Or a practical example of Apple Shark usage.)

Every few years we rent a beach house on a island off of North Carolina and meet up with a bunch of friends from college. During the last trip a group was off body surfing and during one of the wave breaks they noticed something that ended the surfing and started the on shore Corona drinking.

Yep, it was a shark.

Apparently it was just a little guy, only a few feet long, but there is really no bigger incentive to get out the water than one of those. Thank you very much for that Steven Spielberg.

“Where’s all this rambling going?” you’re probably asking yourself at this point. Well, its actually a crude play on words tie-in to an application that seriously helped out yesterday.

I was sitting at my desk, innocently minding my own business, when one of the TestTrack guys came over and asked if I could run a test for him. Apparently some code they were working on was running ok on Windows, only taking a few seconds, but on the Mac it was chewing up like five minutes.

WhatchyoutalkinaboutWillis? That’s not good.

A quick sanity check run showed that indeed that section was running with all the speed of a Geo Metro in a strong headwind. Dejected, the TestTrack guy started to walk off to try to find out what the heck was going on.

Me: “Hey hold on, we’ll sic the Shark on it and find out what’s up.”

TestTrack Guy: “Greg Norman?”

Me: “No, not Greg Norman. And if you say Jabber Jaw next we’re going to have to have words.”

So I fire up TestTrack again but this time I attach to it using Apple’s Shark profiling application. We hit the slow spot, let it crank for a little bit, then stop our sampling. Shark then chews (ha!) over the results for a minute and spits out (get it, chew, then spit out, double ha!) the timing graph of our sample. Looking down the result list things don’t seem so bad:

We keep scrolling down and notice a percentage jump between a call from our code to the Qt code. A sizable percentage jump too, we’ve found our first clue.

Following the highlighted items to the right (I’ve had to cut down the screenshot to fit in this post) we see that slowdown is happening in CTTLookup::GetText. This is a method that we use get text to be rendered on the screen, which means it is called about a bazillion times.

Double clicking on the CTTLookup::GetText string Shark opens up the source file with some percentage listings of how much time was spent processing on each line. Using those, and noticing in our call stack that the Qt locale code was running all over the place in Apple’s system libraries we found our slow spot.

Some quick refactoring to make sure that locale call only happens once instead of every call, a new compile, and presto the Mac TestTrack client is now running just as fast as the other platforms. Total time from Shark start to fixed code was probably five minutes. And we didn’t even need a shark cage, or a caddy, to do it.