We are very, very bad at what we do, yet somehow get richly rewarded for it.

We've even invented a new performance problem: intermittent performance. Performance isn't just poor, it's also extremely variable due to distributed computing, lamba, whichever. So users can't even learn the performance pattern.

Where chip designers move heaven and earth the move compute and data as closely together as is physically possible, leave it to us geniuses to tear them apart as far as we can. Also, leave it to us to completely ignore parallel computing so that your 16 cores are doing fuck all.

You may now comment on why our practices are fully justified.

In the days of programs taking forever to load or web pages downloading images slowly we knew what technical limitations were there.

Now we know how much sluggishness comes from cruft, downright hostility (tracking), sloppy developer work, etc.. we know this is a human problem and that angers us.

But for non-technical people it hasn't changed too much. Computing wasn't super pleasant 25 years ago and it's not now. Instead of waiting half a minute for Word to load they wait 4-5 seconds for Spotify to load. They were never interested in Notepad or Cmd or Paint. It doesn't bother them that now they open slower than in 1999.

Another quibble I have with the article is the statement that the visual effects on macOS were smoothly animated from the start. This is not so. Compositing performance on Mac OS X was pretty lousy at first and only got significantly better when Quartz Extreme was released with 10.2 (Jaguar). Even then, Windows was much more responsive than Mac OS X. You could argue that graphics performance on macOS didn't get really good until the release of Metal.

Nowadays, I agree, Windows performance is not great, and macOS is quite snappy, at least on Apple Silicon. I too hope that these performance improvements aren't lost with new bloat.

I run a machine with lots of RAM and a hefty CPU and a monster GPU and an SSD for my Linux install and...a pair of HDD's with ZFS managing them as a mirror.

Wat. [1]

I also have Windows on a separate drive...that is also an HDD.

Double wat.

My Linux is snappy, but I also run the most minimal of things: I run the Awesome Window Manager with no animations. I run OpenRC with minimal services. I run most of my stuff in the terminal, and I'm getting upset at how slow Neovim is getting.

But my own stuff, I run off of ZFS on hard drives, and I'll do it in VM's with constrained resources.

Why?

While my own desktop has been optimized, I want my software to be snappy everywhere, even on lesser machines, even on phones. Even on Windows with an HDD.

This is my promise: my software will be far faster than what companies produce.

Because speed will be my killer feature. [2]

[1]: https://www.destroyallsoftware.com/talks/wat

[2]: https://bdickason.com/posts/speed-is-the-killer-feature/

I think there’s an important additional factor, which is how dynamic so much UI is these days. So much is looked up at runtime, rather than being determined at compile time or at least at some static time. That means you can plug a second monitor into your laptop and everything will “just work”. But there is no reason it should take a long time to start system settings (an example from the article) as the set of settings widgets doesn’t change much — for many people, never — and so can be cached either the first time you start it or precached by a background process. Likewise a number of display-specific decisions can be made, at least for the laptop’s screen or phone’s screen, and frozen.

Here’s some sobering perspective on this from 40 years ago: https://www.folklore.org/StoryView.py?story=Saving_Lives.txt

Linux is probably the system that suffers the least from these issues as it still feels pretty snappy on modest hardware. […]. That said, this is only an illusion. As soon as you start installing any modern app that wasn’t developed exclusively for Linux… the slow app start times and generally poor performance show up.

This is not an illusion. Cross-platform programs suck, so everyone avoids them, right? Electron apps and whatnot are universally mocked. You would only use one for an online services like Spotify or something. The normal use case is downloading some nice native code from your repo.

We should be getting so much more from our hardware! Let's not settle for software that makes us feel bad.

[1] http://www.permacomputing.net/

[2] https://suckless.org/

My initial gut was to blame the modern drawing primitives. I know that a lot of the old occlusion based ideas were somewhat cumbersome on the application, but they also made a lot of sense to scope down all of the work that an app had to do?

That said, seeing Notepad makes me think it is not the modern drawing primitives, but the modern application frameworks? Would be nice to see a trace of what all is happening in the first few seconds of starting these applications. My current imagination is that it is something akin to a full classpath scan of the system to find plugins that the application framework supported, but that all too many applications don't even use.

That is, used to, writing an application started with a "main" and you did everything to setup the window and what you wanted to show. Nowadays, you are as likely to have your main be offloaded to some logic that your framework provided, with you providing a ton of callbacks/entrypoints for the framework to come back to.

For example: you might not want to use Rust because its steep learning curve means you’ll spend more time learning than delivering

Related to that, it might not actually be the case: https://smackernews.com/item/36495667 HN. Key takeaway:

Rumor 1: Rust takes more than 6 months to learn – Debunked !

All survey participants are professional software developers (or a related field), employed at Google. While some of them had prior Rust experience (about 13%), most of them are coming from C/C++, Python, Java, Go, or Dart.

Based on our studies, more than 2/3 of respondents are confident in contributing to a Rust codebase within two months or less when learning Rust. Further, a third of respondents become as productive using Rust as other languages in two months or less. Within four months, that number increased to over 50%. Anecdotally, these ramp-up numbers are in line with the time we’ve seen for developers to adopt other languages, both inside and outside of Google.

Overall, we’ve seen no data to indicate that there is any productivity penalty for Rust relative to any other language these developers previously used at Google. This is supported by the students who take the Comprehensive Rust class: the questions asked on the second and third day show that experienced software developers can become comfortable with Rust in a very short time.

Why oh why won't Apple let you turn this off? It annoys if not nauseates so many people.

This is is just one example, but indicative of their mindset, why I dislike Apple, and use linux whenever I can. It's such a calming joy to switch instantly between desktops without the rushing-train effect.

I think we could all do with celebrating the small. ESP32 and STM32 have hit a point where you can do modest computing tasks on them without having to become an embedded hardware expert to do so. I'm at one of those crossroads in my career and I'm trying to decide if I double down on a new web friendly programming language (maybe Elixir) or jump into embedded.

I've done a reasonable amount of programming in the small, several times tricked into it, and while it's as challenging if not moreso in the middle of doing the work, the nostalgia factor after the fact is much higher than most of the other things I've done.

The architect wanted to break everything up into extremely small pieces, small enough pieces that many were dependent on each other for every single call. Think "a unified address service" to provide an physical address via an identifier for anything that had an address (customers, businesses, delivery locations, etc).

The problem was that it turns out when you're looking up a customer or business, you always need an address, so the customer service needed to hit the address service every time.

Disregarding the fact that this whole thing was a stupid design, the plan was that when you hit the customer api, the customer code would make internal http calls to the address service, etc.

I pointed out that this was a ton of unnecessary network overhead, when all of this information was sitting in a single database.

The whole team's argument was effectively - "it's 2015, computers and networks are fast now, we don't need to worry about efficiency, we'll just throw more hardware at it".

The whole thing ended up being scrapped, because it was crippled by performance issues. I ended up rewriting the whole thing as a "macroservice" which was 60000% faster for some particularly critical backend processes.

Anyway ... I think that mentality is prevalent in a lot of people involved in technology creation, technology has improved so much, moore's law etc etc etc.

So let's not worry about how much memory this thing takes, or how much disk space this uses, or how much processing power this takes, or how many network calls. Don't worry about optimization, it's no big deal, look at how fast everything is now.

a lot of the Windows shell and apps have been slowly rewritten in C#

I worked on the Shell team until late 2022. There is very little C#, if any at all. The vast majority of the Windows Shell is still C++ with a significant amount of WinRT/COM.

Discussion from a few days ago based on the original Twitter thread: https://smackernews.com/item/36446933 HN

But after that, the biggest problem is clearly the framework/language you use. The maxim "premature optimization is the root of all evil" has done damage here. The problem with frameworks/languages is that by the time you finish your features and profile your code, you're already doomed. There's no way to speed up the entire framework/language, because it's part of everything you do - death by a thousand cuts. Nothing you do can improve upon the fundamental fact of running in an interpreter, with a garbage collector, with complex layout calculations (a la HTML/CSS instead of Win32), or with major choices like processes over threads, sync IO over async IO.

GIMP will stall for 10-15 seconds at startup looking for XSANE plugins. Apparently it's calling some external server, bad in itself, and that external server is slow. Worse, this delay stalls out the entire GUI for both GIMP and other programs.

There's no excuse for this "phoning home". Especially for XSANE, which is a rather bad scanner interface.

1. Serve ads.

2. Consume content.

3. Compress audio and video input and upload it to someone's servers.

None of these requires a responsive UI. Ticket closed, works as designed.

Windows always used to have that fresh lightweight install vibe. But as soon as it started indexing, doing updates, and virus scanning it would drag to nothing. Along with all those system tray apps that would take an age to fire up.

Partial suspend to disk made things boot faster. Like not doing the whole driver scan thing on boot. I don't know if Linux has ever taken this on board. It's a blessing and a curse as Windows doesn't like being ported to another machine, whereas my Debian disks I can swap between some desktops and laptops without much issue.

There's also that weird delayed animation thing, that is meant to feel like polish. But slows down desktops. Weird animation effects and what not. I tend to run XFCE and turn off any thing like that.

I'm using a Chromebook right now and this is an old machine, but still feels pretty snappy. Certainly weird and wonderful experiences between hardware. I have High Sierra on an SSD on my Mac Mini, and that's slower by far to boot than my Linux Arch box on the same age hardware. Having said that the UI always feels more responsive as it's tailored for that.

Linux suffers lots for me with kcompactd or whatever it is. Some weird memory disk swap stuff. If I accidentally code an infinite loop my machine turns to complete mud, and takes about 5 minutes to recover. Whereas it boots to the browser in under 1minute. Weird huh?

While this may not be the only explanation for why this trend continues, I think it's *spot on* to explain why this continues in commercially-funded software.

I've not started an app so far today, not sure I did yesterday either for that matter. I certainly created plenty of tabs in chrome, and new terminal windows, but those just pop as instantly as far as I can tell.

Oh, and i'm on MacOS

What we need instead is a way to persist the process or even whole sandbox to disk and then fork off new instances from that. That's much less work and much more effective than piecemeal optimizations (AOT, native code, etc.). Unfortunately, existing platforms and frameworks do not support forking, let alone forking from persisted app image.

On one hand, lag is real. I rebooted my M1 Mac mini yesterday running Ventura, and while it only took a few seconds to boot to the desktop, it took, like, two minutes for it to stop beach-balling and finish initializing. (It was most likely waiting on network I/O to finish, but still.)

On the other hand, machines are faster than ever before while doing more than ever before, and apps are more flexible and change more quickly (largely in part to super approachable cross-platform frameworks like Electron). A few milliseconds of UI latency will bother almost no-one.

On the other _other_ hand, Julio's demo of using Windows 2000 on an time-appropriate machine is best case. I definitely remember waiting what felt like eons for lots of useful apps to load, like Office and Internet Explorer. (Remember when browsers had startup screens?)

He's definitely right about how far hardware has come since 1999.

The shift to Apple Silicon was even more transformational than the transition to SSD, IMO. Julio's right in that the shift to SSD was night-and-day, but going from an Intel Mac to an Apple Silicon Mac sped up literally everything you used to an insane degree AND you got 12+ hour battery life to boot.

This used to be an either-or kind of trade-off, and for Windows devices, it still is.

To wit: I used an Intel Mac Pro (the trash can) last week for some audio work, and that super expensive almost-server-class machine was _slower_ than my base model M1 Mac mini at home, while running (slightly) louder and hotter!

Slack on the other hand...

</nitpick>

Then the SW and Product teams would catch up, add more crap and it’d be time for a new machine.

It seems like that cycle has ended and HW will never catch up again at this point.

Clearly the modern machine is slower while still being significantly more powerful so it's doing a lot more stuff, but how valuable is that stuff?

Nobody prioritizes performance anymore unless for the critical cases where it matters (video games, transcoding video, and the like). What people (companies) prioritize is developer time. For example: you might not want to use Rust because its steep learning curve means you’ll spend more time learning than delivering, or its higher compiler times mean that you’ll spend more time waiting for the compiler than shipping debugging production. Or another example: you might not want to develop native apps because that means “duplicate work”, so you reach out for a cross-platform web framework. That is, Electron.

Small but important disagreement IME: what companies prioritize is time to market which is often the same as developer time but importantly different in one key way: it means it's no longer an issue of "lazy developers" but it's a market question of "what will users tolerate."

I don't say that just to shift blame, but because it's really key to understanding what's going on - as the article notes, performance "where it matters" has gotten better and better over time.

We also have a few other improvements in the last two decades that have made things like "app startup time" less important for the market: OSes that don't need to be restarted every day, and enough RAM (and good enough memory management) to manage running a ton of open apps/windows/tabs without manually quitting and re-opening apps all the time.

Would you pay more for a Notepad that opened in 0.1s instead of 2.0s or whatever? Would you give up other features? Certainly a lot of people on HN likely would - and many probably already are running Linux (hell, I am on one of my machines as a daily driver) which hasn't had the same "ship features fast!!" pressures.

Maybe one year Apple will do another Snow Leopard, or MS will do something similar - https://www.macworld.com/article/191006/snowleopard-3.html - but right now most folks I know are enjoying the features, even the ones that we power users often find superfluous or downright annoying.

Like a standard GUI test suite. One click and it's measured. It could ignore or use predefined times for each network query.

Just look a bit further down the front page of HN today and you'll find a legitimately-heated debate regarding whether ORMs bring value or no. But, who can blame the developers? The pressure from management is eternal and some of us like to spend our time on non-computer problems too. Reaching for a JSON serializer or ElectronJS over Win32 and raw SQL is an understandable decision when presented with real-life pressures.

I think if we want to see good user experiences, the capitalists and management will need to start prioritizing them again (at their own expense). This is a very difficult narrative to sell, but I've had some traction in my company with "higher order consequences of good UX today means more sales in the future" kind of talk. There is also a story about pride in the product and the improvements this brings for internal operations. Imagine if your executive leadership came into the room, smack talked the electron JS pile and insisted it be rewritten from scratch while targeting native toolchains? Would that be enough of a fire to get the average developer to start thinking again or are we too far gone at this point? Clearly, we are mostly beyond the phase of "valiant developer works overtime to strive for better UX despite any and all mgmt pressures".

Modern software does have bloat, and I think we need to fix it, but modern applications are doing far more than just slamming in a text file. In 2000, OSs and apps weren't connected to anything. Their functionality was miniscule compared to what we have today, and they crashed all the time. Losing your work was a constant, which is why people learned to make constant backups.

I loved win2000, but I'd never go back there (although I would like advertisement to stay the hell out of my OS!)

I don't think many of these programs are used by the people who write them.

(I've been on *nix land for a decade now — I wish my Mac (intel) was a bit more snappier, but I'm happy nevertheless).

The problem is that modern package management tends to "drag in" unnecessary dependencies, each of which has to be loaded, remapped, virus-scanned, CRC-checked, etc...

The new Calculator was loading NVIDIA libraries, Windows Hello 4 Business Password Recovery helpers, and a decent chunk of a web browser.

Why?

1. Calculator gained some basic graphing capabilities, so it calls some DirectX functions, which call NVIDIA functions, which... drag in hundreds of megabytes of game driver garbage, including Event Tracing for Windows (ETW) circular logs that NVIDIA uses to spy on you. Err.. I mean "improve software quality".

2. It uses web requests (e.g.: currency conversions), which might need to go through a corporate proxy, which might need authentication, which might need Windows H4B, which might need a self-service password reset.

3. The aforementioned web requests use HTTPS and HTTP/3, which then drags in QUIC, a bunch of cryptographic libraries, CRL checking, Enterprise PKI policy, etc...

The hiccup is that all of this "work" is being done by the Calculator app itself, not the operating system. The OS just provides the DLL files, it doesn't pre-cache them in any meaningful way any more. These are all user-mode libraries, so each application has to load and process them in full.

Even in web development, you get the same effect. A small web site in ASP.NET / C# might have been 500 KB in the past and would load in milliseconds and then take 50 MB of memory. Now? If you add the new "session state" plugin, it drags in Azure SQL support, which needs Azure Active Directory Authentication, which needs OAuth, which needs JWT, which needs a JSON parser, which needs the new UTF8 decoders, which needs the new Memory/Span code, etc... That 500 KB app instantly bloats to 350 MB and takes 10 seconds to restart!

In NT4 and 2000 authentication and web proxies were "ambient" services provided by the OS, and much of it was in the kernel or pre-loaded and shared by all applications.

Summary:

The transitive dependencies of user-mode libraries are always processed in full. There's no compile-time "trimming" at this level. There's no try dynamic loading any more either, "dynamic" libraries are loaded statically because of hash-verification and anti-malware checks. There's no sharing any more to avoid DLL hell. All of the above also breaks the older optimisations where code was paged in dynamically.

The result is that it is "so easy" to write code now, but impossible to make it launch fast.

I think you somehow don't have any idea what a "driver" means in a computer hardware context like this.

(There's an averaging effect to. That game paying customer might like it if Windows was snappier, but in that market they're just another voice in the crowd of people who on average are satisfied with the current status quo.)

"Paying customer" is important too because you can almost measure how much social power the user has by how slow the software is. Why is the point-of-sale device in the checkout miserably slow? Why does the device the desk receptionist is using at your national-scale bank need 30 seconds just to pull up your appointment information? Those people have no social power, so they get to just sit and wait while the computer swaps things in and out for a truly simple task. Executives get machines that can switch between email and the browser in a heartbeat with the other 24 gigs of RAM and 6 cores do nothing. Using what machines the developers get as a metric for how much the company cares about them is something smarter developers have been doing for a while; if your developer interviewer uses the 8 minutes it takes their machine to boot to sing the praises of the engineering culture the company has, well... make appropriate judgments.

(In 2023 this almost impresses me. Setting up a computer that needs 30 seconds to switch between a calendar and an email is almost a challenge now. You need to harvest those last few precious $10/unit to give them really shitty hardware and combine it with an almost sociopathic dedication to layering on enough virus scanning and tracking software to slow down a cheap machine even so. Even the cheap stuff shouldn't be that slow!)

If you work at it even a bit on Linux, you can set up a very responsive system. You've been able to for a long time, really. But you may find you don't get to use the latest and greatest of the heaviest weight desktop system at the time. It's a lot easier on Linux to use the stuff from years ago that flies now. Emacs use to be joking referred to as "Eight Megabytes And Constantly Swapping"; now it's a "light-weight" text editor. (Though it doesn't quite start instantly for me, it is under a second in my configuration. YMMV.)

Because the old software is missing 80% of the features needed today.

It's like comparing a go-kart (simple, fast, easy to use) with a car (big, slow, complex). Yet you don't see people in go-karts.

Don't throw this on devs. Attempting to fix the problem on dev side would cost billions of dollars worldwide and it would probably fail. Meanwhile, proper app sleep modes across all OSes is a comparatively small million-dollar project.

Personally, I am not going to invest a single second of my time into optimizations of app launch if I can avoid it. If you are bothered by app launch performance, go hack app sleep states into Linux or other free OS instead of shouting at devs.