A post like this is begging and screaming for concrete numbers. I want to see - initial perf, perf with Apple sampling, perf with hookshot instrumentation, perf after fixing issues found via hookshot.

Fair point! It's hard to assign numbers to perf for something like an entire application - a lot of the wins we found were places where the main screen was locked (causing app un-responsiveness) or where we were able to change the order of some actions to get the app to render quicker.

I'd say the app takes around 2-3x less time to load than when we started our most recent performance quest, largely due to issues we found using hookshot. We did find some performance critical inner loops in our rendering code where we were able to achieve something like 10x speed-ups.

Apple's profiler has significantly lower overhead than hookshot - which makes sense given the relative amounts of information collected. Our app runs noticeably slower when hookshot is enabled, but when it is disabled, hookshot introduces exactly 0 overhead. We only enable it when we're specifically debugging performance issues.

Would love to see a concrete example of where this helped out. What's going on that's so complex under the hood?

One example that comes to mind: we have a networking layer that prioritizes some HTTP requests over others. For example, we seed our cache by firing off requests for the next 30 days, but at a low priority. There was a bug in this layer where request initiation could block the main thread while unrelated work was finishing.

Another example: we used the "HOOKSHOT_TAG" macro to tag objects related to rendering different days in Cue (today, yesterday, tomorrow). This makes the thread activity graph use different colors for time spent on those objects. This helped make obvious a few edge cases where some rendering/processing for a day that was not on screen was done before the day that was.