nee.lv

Casey Muratori has some great YouTube videos (a.k.a.: rants) about the end-user visible performance degradation over the last two decades despite computers becoming 10-100x faster by various metrics.

E.g.:

Visual Studio Rant https://www.youtube.com/watch?v=GC-0tCy4P1U

How fast should an unoptimized terminal run? https://www.youtube.com/watch?v=hxM8QmyZXtg

The root cause is that Microsoft simply doesn't have performance as a priority. It's not a KPI for (almost) anyone, certainly nobody in the desktop teams. Upper management doesn't prioritize input latency over telemetry or advertising "features". It's that simple. There's no pressure, no rejection of slow code, no metrics, no pride in good engineering. If it barely functions, it's good enough to ship.[1]

Microsoft employees will occasionally comment to say otherwise, but their statements are contrary to easily verifiable facts, such as massive performance degradations in trivial tools such as the new Notepad, the new Terminal, and the Calculator app.

The actual specific technical reasons include:

- Executables used to be loaded from disk one 4KB page at a time. Execution could start as soon as the first 4KB block was loaded. For a long time now, executables are digitally signed using a hash like SHA1 or SHA256, which means that large executables can't actually start running any code until the entire file is loaded. The obvious fix -- that didn't occur to anyone at Microsoft -- is to use a Merkle tree hash instead of…

> They may well be optimizing for a median gaming PC instead.

This is how you get games that could run good if the user got more control over the model LODs, post processing effects and even render scale, but the developers/project management didn't care.

What's worse, a lot of modern games have great ability to scale back and run on lower end hardware when necessary, but the companies behind them only care about that ability when it comes to getting them running on Switch or a similar constrained hardware environment, that would still let them rake in more cash.

And outside of particular hacks (messing with config files, or using untrusted utilities), the users are often left powerless because a few configuration variables weren't exposed to them for whatever reason.

That's actually worse than Electron apps that are typically badly optimized by default (platform overhead): it's very much like a developer in an enterprise setting choosing to go for the N+1 by looping over data in the app and doing DB calls for each iteration, yet everyone actually is okay with it.

Except for the people who actually don't want their software/game to run slow, just because they cannot afford to throw unreasonable amounts of hardware resources at the problem the devs (and whoever is telling them what to do) inflicted upon them.

Essentially, it's Wirth's law: https://en.wikipedia.org/wiki/Wirth%27s_law

Best counterexample to this is probably e-sports titles that are optimized for stable…

This is unfairly downvoted IMO, because I think you're actually hitting on a very important point. Linux users tend to be enthusiasts, people who love software, and also primarily interact with a community where the "developer/user" is the most important figure, the one whom everything is designed around.

In the Linux community, at least unless a project has a toxic developer (there are a few), bug reports are Always Good. They're how we make the software WE use better on the systems that WE use it on. Even if a report isn't fully actionable (e.g. it's a problem with graphics drivers), the report is often helpful because the bug tracker is probably public and we can try to find workarounds, or at least flag the issue for others.

For closed source commercial software, especially cases where a tiny number of developers are working on the code, bug reports are Always Bad. They represent more work, work that you don't want to have to do, because at the end of the day these are people who already bought the game. You've gotten as much out of them as you're going to get out of them. If they're more trouble than they're worth (someone else in this thread claimed 90% of bug reports out of 1% of purchases), then it's obvious you should just ignore them or not port your game to their platform at all. You'd think this attitude would be different for issues that affect a lot of people: a good bug report can help you fix widespread problems that are hurting your players, but actually…

> Repairability? Other concerns, things that change the day-to-day use of the device, should weigh more.

I don't think repariability is something you need to put effort into build into a product, it's something you put effort into taking out of a product. Apple's engineers definitely have things like what Louis uses for his repairs: board views, schematics, diagnostics software. Louis gets these things from illegal vendors in other countries who obtain them from Apple workers. If Apple just sold these things to him he'd be willing to pay but that's not in Apple's best interest.

Also, Apple prevents Louis from buying replacement parts because they make their vendors agree to never sell the components they use to anyone but apple.

> Other concerns, things that change the day-to-day use of the device, should weigh more.

This avoids another massive externality: recycling and the environment. Right now Apple's recycling program takes old mostly working systems and shreds them. There's a reason we should: Reduce, Reuse, and Recycle in that order.

> So maybe only these component failures are left. Reverting to the old methods of replaceable components would likely re-introduce a massive class of problems that have by and large been eliminated.

The macbook repair community was at one point fixing a very common issue by replacing a component with a slightly higher spec part. The difference was 1/1000 th of a cent to 2/1000 th of a cent in cost or something like that. Multiple…

This was a good read and great work. Can't wait to see the performance tests.

Your write up connected some early knowledge from when I was 11 where I was trying to set up a database/backend and was finding lots of cgi-bin online. I realize now those were spinning up new processes with each request https://en.wikipedia.org/wiki/Common_Gateway_Interface

I remember when sendfile became available for my large gaming forum with dozens of TB of demo downloads. That alone was huge for concurrency.

I thought I had swore off this type of engineering but between this, the Netflix case of extra 40ms and the GTA 5 70% load time reduction maybe there is a lot more impactful work to be done.

https://netflixtechblog.com/life-of-a-netflix-partner-engineer-the-case-of-extra-40-ms-b4c2dd278513

https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times-by-70/

I don't think you've been following this story. If you looked into the technical details [0], and surrounding context, you would understand why your comment isn't particularly insightful. For example, terrain has nothing to do with this bug and it isn't a complex fix that interacts with "millions of lines of code." A single run of a profiler would have caught this.

I also think it's relevant to note that GTA V has sold 140 million copies, 20 million last year alone, and Rockstar makes hundreds of millions of dollars a year on the title. For a multi billion dollar product to have a known, relatively simple, problem is shameful. I don't know what went wrong, but I don't think it was the competency of engineers or the complexity of the problem that allowed this to fester.

[0] https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times-by-70/