I'm not particularly leaving Twitter, but I am spending a lot less time here. Most of my posts are now on and that's where I spend more of my time reading. I'll post to Twitter for things that need more reach, and I still look at Twitter every day or two.

A short anecdote on getting answers on the modern internet:

A Reminder About NSRange and String:

Big-O matters, but it's often memory that's killing your performance.:

Pull Requests are a story:

Life comes at you fast. In a few weeks, my "I'm bored" muscle memory has gone from "tw\n" to "mas\n". (after "sta\n"). I think this wake is premature. Things can shamble on a long time (livejournal). But still, Mastodon has already replaced this for me. Took 2-3 weeks.

I've never had a response from Apple so fast & helpful through dev forums (not counting Swift forums). Even though the answer is "this isn't possible, please open a FB," that's totally fine, and for once in a long time, I was happy to open the FB.

Any custom Instruments experts out there? Maybe this is just a limitation in Instruments to keep it faster?.

RT @krzyzanowskim: Invitation:

RT @dee_bosa: About Friday at Twitter HQ - I didn’t do enough to confirm and I regret the mistake

Is there really no written usage documentation for RegexBuilder? I see one small example in the docs. But I can't find anything else. (That said, @k_katsumi's is brilliant and helped me a ton figuring things out.).

Spent today chasing this one down. The error message is a lie. The solution is a little ugly, but not difficult and should be quite robust.

Solving "Required kernel recording resources are in use by another document" in Instruments.:

RT @menotyousharp: @cocoaphony I always find these types of discussions interesting. Optimization is hard and I keep finding examples wher….

RT @lizardbill: How to write a great Stack Overflow question

Side note: writing this with async/await and GCD have identical (even if poor) performance. The async/await is nicer to write. So definitely a win for async/await. 👍🏼.

Optimizing the parallel code is forcing me to think deeply about Swift implementation details. Conversely, optimizing the sequential code has mostly been "Run Instruments. Where is my code spending its time? Rewrite that little piece. Repeat.".

Just rewrote one very over-clever Dictionary(grouping:) as a for-loop and sped things up more than throwing 4 cores at the problem. Despite using structs exclusively, my parallel code is getting bogged down in ARC for COW. More cores just makes it slower because more contention.

May I remind us all again to first optimize on a single core, and *then* worry about making things parallel (if that's even needed). It's harder than it sounds to make parallel algorithms fast.

Whoa. After Apple letting so many conferences whither for lack of support, is there finally change? I’m hopeful this isn’t a one-off. Thank you. The community has needed Apple’s support for so long, and it means a lot to see it.