[abhayb]

I love the detail in the post! A lot of this seems to boil down to the author being able to drop to a lower level of abstraction when necessary. I'm curious to know how they got that facility. Did they dig deep when they found something was slow? Or did they do a bunch of research before hand? Maybe the higher level tooling didn't exist when they started working on the platform so they had to pick things up out of necessity?

[toast0]

> A lot of this seems to boil down to the author being able to drop to a lower level of abstraction when necessary. I'm curious to know how they got that facility. Did they dig deep when they found something was slow? Or did they do a bunch of research before hand?

I'm not the author, but I've got this facility as well. I guess part one is to have motivation --- it's hard to know what to research before hand[1], but if you've got something that is actively too slow now, that gives you a clear direction. Part two is not being easily satisfied that things are fast enough, or fast as you can get. There's almost always a way to make UI faster, it's just a matter of what needs to break to make it happen, sometimes it's abstraction layers. You can go back in time and look at 1980s UIs and while some were slow, many were super fast, and yet the CPUs were slower than dirt compared to today. We're often marshalling a lot more data and pixels, but it just shows than processing everything in time for the next frame is a reasonable target. Learning to use the profiling tools available is a good concrete first step.

[1] But, don't let that stop you from research into things that are interesting to you, or seem like they might be useful. Knowing something can be done is immensely helpful to doing it, even if you don't remember how it was done.

[chrisbrandow]

Knowing what little I do about the author’s experience, his facility in dropping to lower levels probably has a lot to do with his having worked extensively at those lower levels out of necessity in the past.

[abhayb]

Ah I wasn't even thinking about motivation! Yeah it makes sense that I'd have to start with motivation when I'm breaking down a perf problem. I'm reminded of the talk So you want to be a wizard [1]. It definitely understands what you're talking about.

[1] https://jvns.ca/blog/so-you-want-to-be-a-wizard/

[inimino]

Don't forget overcoming fear. SICP helped me most in that I overcame unconscious barriers of fear of complexity. The only way to defeat those is to embrace complexity and fight through it.

[cpach]

Yeah, it’s impressive indeed. Simmons has been developing macOS applications for a long time, e.g. when he worked for Omni Group. Here’s an interview from 2003 where he talks about an early version of NetNewsWire: https://daringfireball.net/2003/03/interview_brent_simmons

[wiredfool]

He’s been doing Mac applications since the late 90s, when he worked on Userland Frontier,

[abhayb]

Ah dark knowledge through blood sacrifice. Was hoping they'd found an easier way :( Thanks for the pointer, been a bit since I read some OG John Gruber

[ken]

There's no black magic here. Everything you see here can be found by running the profiler and reading the docs. I haven't been a Mac developer nearly as long as he has, and almost all of these are things that I do.

[setpatchaddress]

Mostly, yes; but the folklore like (paraphrasing) "don't use Core Data for this particular purpose" is also critical and isn't as easy to come by except through bitter experience (or war stories from other developers, if you're a good listener).

There are no true shortcuts.

[ken]

It’s clear from the docs that CoreData can use SQLite internally but doesn’t give the programmer full access to all the features of the database. No bitter experience necessary.

[inimino]

The bitter experience is needed to learn that there are no shortcuts, and that the higher-level library that makes everything easy for you will also bite you in the ass sooner or later. We aren't born knowing these things, sadly.

[developer2]

Aside from the specific optimizations listed in the article, and caring about improving round-trip times for remote API calls in general, the fact is that any app built properly with native MacOS/iOS APIs will be extremely fast.

Apple's APIs for macOS and iOS are simply better than those provided by either Microsoft (for Windows), Google (for Android), etc. Apple's APIs are, for the most part, very well-thought-out; their engineers have put together fantastic layers in the operating system and its UI components. The primary reason so many apps perform poorly on Apple platforms is because those apps were developed using 3rd party cross-platform tools (eg. Electron, or making an iOS app with webviews rather than native elements).

Developers who make efficient use of Apple's APIs, and who spend time to reduce their backend response time on remote API calls, will always produce an amazing product. The best example I can think of off the top of my head is the Apollo app for Reddit on iOS; it is coded with 100% native platform APIs, with no slow cross-platform garbage. It's such a breath of fresh air to witness.

[saagarjha]

> the fact is that any app built properly with native MacOS/iOS APIs will be extremely fast

Nope, you’re reaching too far. Applications built using native frameworks will have a strong push to generally do it right, but nobody can save you from an O(n^2) loop. And even with native frameworks and engineers with access to the best resources, you can totally mess up: take macOS Catalina’s Activity Monitor app, which takes up approximately half a core updating a table view every second, which it managed to do previously with a mere fraction of the resource usage. You can’t fix everything.

> The best example I can think of off the top of my head is the Apollo app for Reddit on iOS; it is coded with 100% native platform APIs, with no slow cross-platform garbage.

Apollo is not cross-platform, but it doesn’t always use native platform widgets as I have pointed out to Christian in the past. I don’t think this has had a major performance impact, especially since they aren’t in the most computationally expensive path, but those parts probably do not interact with the platform at the layer you think they do.

[developer2]

1. I did not mention Apple's own native apps as a perfect example. I have also noticed Activity Monitor as an imperfect sample. I'm not sure if it's a limitation of the APIs available, or if Apple engineers just fucked up. I 100% agree that Activity Monitor takes up far more resources than it should. Then again, monitoring every single process (plus thousands of threads!) running on an operating system is an intensive undertaking, so I'm not entirely sure who to blame, if anyone.

2. I will 100% defend Christian until the end of days. I respect the fact you at least know his name, assuming that you can in return understand that everything he does is amazing. Yes, some of what he does directly counteracts the weaknesses that are innate to the Apple platform (which should be called out against Apple). His most recent release, for example, offers a "Smart Rotation Lock", which swaps between portrait and landscape depending on whether a GIF or video is playing; something Apple should have built in from day one. Also, he had a volume bar in top-left corner on iPhone X and beyond before Apple even made that standard. IMO everything he does to break the "Apple philosophy" winds up getting adopted by Apple. Christian is that good.

3. Everything I said above, whether already existing at Apple or pushed towards the future, is already better than Windows or Linux. MacOS and iOS are positioned to take over the future of computing, minus one mother-fucking aspect (fuck you, Apple): gaming. Even if Metal is technically superior, vendor-lock at Apple makes Metal worthless vs. DirectX and OpenGL. This is the only thing I am willing to abdicate… Apple+MacOS+iOS needs to figure out how to play nice with cross-platform gaming.