Lately we had performance complaints from Sourcetree users even after a series of optimizations took care of the obvious issues we could find. While we could see spin logs for various paths that were still heavy, there was nothing jumping out anymore.
At this point I needed more data to help spread out more of a map to guide me to the problem. I broke out Instruments and created the template pictured below which I’ve lovingly dubbed “The Sledgehammer” 🔨
With this in place the frequent disk accesses for typically unused preferences in theme coordinators showed up along with their dangling KVO objects. The stutters made sense.
A bit of refactoring narrowed the scope of both KVO and prefs reading to the minimal areas necessary and we’re back to having a happy little 🌳
After sitting down with the Xcode debugger I stepped through and verified all theming code and appearances were still correct and being hit. Next up was checking the visual hierarchy for what view was problematic.
Poking around further I found that particular view wasn’t set to -wantsLayer. Previously it picked this up implicitly.
One line later and we’re back in business.
Recently we had a high volume crash in Sourcetree with a limited user count. Roughly 4 crashes a week per user in an onscreen notifications helper.
The posting object was alive along with all parameters. The code hadn’t changed in years. What could be the culprit?
After much staring and noodling (no pun intended) I realized that Asiatic languages reordered parameters without positional notation. Hint: 0x000008 means your integer was read via %@ in a format string.
subscribe via RSS