Fast Software, the Best Software
Speed in software is probably the most valuable, least valued asset. To me, speedy software is the difference between an application smoothly integrating into your life, and one called upon with great reluctance. Fastness in software is like great margins in a book — makes you smile without necessarily knowing why.
[…]
That said, Sublime Text has — in my experience — only gotten faster. I love software that does this: Software that unbloats over time. This should be the goal of all software. The longer it’s around, the more elegant it should become. Smooth over like a river stone.
[…]
Similarly, I started using Lightroom around 2007 because it was so much faster than Apple’s Aperture. But Aperture is gone and Lightroom has not smoothed out over the years. Lightroom is a gangly blob, with lots of dull, slow edges. Why can’t it get faster?
Lightroom is getting faster, in places, but overall it still feels really slow.
Via John Gruber (tweet):
One of the confounding aspects of software today is that our computers are literally hundreds — maybe even a thousand — times faster than the ones we used 20 years ago, but some simple tasks take longer now than they did then. Opening the Web Export dialog in Photoshop, for example.
macOS save dialogs seem slow in general these days.
If, on the third call, the width is 150 — between 100 and 200 — and the cached height for 100 and 200 are equal, then the height for 150 is necessarily that same height. We can avoid text measurement and just return the cached value. (And we keep the cache from growing on each call.)
[…]
Note: this is all because I don’t use Auto Layout on table cell views, for performance reasons. I use Auto Layout everywhere else — just not on table cell views.
Update (2019-07-29): Brent Simmons:
Use a truncated version of the text rather than the entire text. For the truncation limit, come up with a length that is beyond what could conceivably fit in the space.
This way text measurement will be faster since it’s measuring less text.
Update (2019-08-01): Ruffin Bailey:
I think this is a lot of why software runs slowly. And it’s not simply that devs use better hardware, it’s that the difference between great hardware and bottom of the line – all the way down to below-TracFone-level Android phones in third world nations – is much greater than we (as devs) ever anticipate as we code and develop.
Unless devs develop and test on representative hardware, they’ll never truly value their app’s performance.
First: some speed changes are illusions. Lots of things we do on today’s computers seem slower than the corresponding operations we did ten or twenty years ago, but often that’s because “the same thing” is thousands of times harder. We assume elegant typography everywhere; that takes lots of work where we used to think the VT-100’s monospaced fonts were elegant.. We want to open a document: where a folder back then might have a dozen documents on a disk with thousands, now the folder has a thousand documents and document-versions on a disk with millions.
[…]
Significantly, no new Tinderbox user and no sales prospect is likely to encounter a document this big: it takes times to make that many notes. We can’t expect the speed bump to have much impact on sales. So, the cost of the speed improvement has to be born either by Eastgate or, through upgrades, by the Tinderbox community.
[…]
In my experience, between 30-50% of improvements like this one turn out to be illusions: they work for simple cases but overlook some edge case that either requires lots more engineering or that vitiates the whole thing.
7 Comments RSS · Twitter
I even think that a Mac that’s half as slow as the current iPhone can get more work done faster. iPhones have crazy fast chips in them and I still feel like they are really slow and awkward for doing most tasks. The only advantage is that they are pocketable. Other than that, if my Mac is around I find it’s often faster to put my iPhone down, open my Mac, log in, launch apps, open files, do the work that needs to be done, and close my Mac... before I’d even be 50% of the way through completing the same job on my iPhone.
It's very easy to agree with this post. Fast software is surely the best software.
And it's not just raw speed that matters, but also reducing other kinds of friction. You want to find software with an interface that matches the way you're thinking. When an app requires you to change your mental model, contort your data entry, noodle around in confusing UIs, or otherwise spend time not directly related to finishing a task, those are all ways to lose time– more ways to break flow.
The only point to which I disagree is the complaint about the standard system dialog asking whether or not to discard a draft document. Craig says the change in the button title from "Don't Save" to "Delete" is confusing because he doesn't know if or how the file was saved. Well, if you're seeing that Apple alert then you know it was autosaved. If the file had earlier been explicitly saved by the user, then closing it would not trigger an interruption of any kind; autosave would simply occur automatically. This is all standard behavior since it was introduced by macOS 10.7, which as Craig notes, was many years ago. The button title is accurate; there is a deletion occurring. It is "violent" as he says. User data will be lost.
@Michael Tsai: The slowness of macOS save dialogs is something that really bothers me. It's probably one of the most seen system dialogs, so making it smooth and snappy should be priority. And yet, ever since sandboxing was introduced and the save dialog implementation changed to be out of process via xpc for security reasons, it's been laggy. It's definitely faster these days — I used to be able to leisurely count full seconds for it to slide down — but I still feel my breath catch the first time I wait for a save dialog to show in an app. Subsequent appearances within an app seem quick enough.
@Ben G: I absolutely agree with that. I'm almost always happier getting work done on a Mac, even if the same job can be done on iOS. Things are usually faster on a Mac because there's less friction in sharing data between apps, switching context within an app, having full keyboard control, etc.
@Martin And now, with Catalina, we get the slow sandboxed open/save panels for all apps. It does help, somewhat, to reduce the animation time:
defaults write NSGlobalDomain NSWindowResizeTime .001
Then you don’t see the sheet sliding down.
Thanks for the tip Michael, that worked nicely :) I settled on a slightly longer time (.07) so sheets don't just pop in, but it still feels much snappier.
Now if only there were an as easily adjustable setting to reduce Xcode's refactoring folding animations...
