Molly Rocket
3 HN recommenders · recommended in 18 months, 2020–2026
38:20 · 158K views · Apr 5, 2020
Casey Muratori responds on-stream to a dismissive Twitter post by demonstrating how slow Visual Studio's startup and debugger watch window are, comparing it to much older software and machines. It is a long rant about software performance and bloat.
HN commenters cite it as the canonical concrete demonstration that modern developer tools got slower despite vastly faster hardware.
20 comments from Hacker News
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 this video How fast should an unoptimized terminal run? [LINK] 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 a linear, single-threaded, whole-file hash like SHA256. - Similarly, anti-malware
I try to use a debugger whenever I can. Unfortunately, I develop on Linux, so the debugger situation here is awful. Basically almost all debuggers are based on gdb or lldb in true Unix fashion parsing text to generate a GUI... They tend to break really fast IME, since text doesn't provide good stability/reliability guarantees (no type checking, no nothing) and even when they do work, there is a lot of visual delay in the feedback loop, which makes them a pain to use. Another problem is that often the debug builds of things at work run too slow to be practical, or they're too big to fit on the target device. My use of debugger at work usually boils down to getting and translating stack traces from core dumps we receive (on command line). There is a very rare occasion that I can do something on my local machine and then I use a debugger. Life is too short for 15-45 minute add logs + compile cycles. I also use bpftrace whenever I can. At home I write Rust, but IME templates don't play well with the debugger, so I usually fall back on prints and bpftrace again. But generally I'm convinced that using debuggers could be a big productivity boost. Here[1] you can see a demonstration of how smooth working with a debugger can be, in this case it's RemedyBG. But forget about this level of comfort on Linux. The whole video may be also worth watching if you like rants and want to see how Visual Studio debugger quality dipped over the years (first the current VS debugger is shown, and then
It may be true that people are partially looking back in rose-tinted glasses, but there's more than just an inkling of truth to their side. Casey Muratori (game developer for the Witness) has a really good rant [1] about bloat in Visual Studio specifically, where he demonstrates load times & the debugger UI updating today vs on an Pentium 4 running XP. Whether or not you attribute the performance difference to new features in Win10/VS, it's worth considering the fact that workflows are still being impacted so significantly on modern hardware. We were able to extract 100s of times more out of hardware and gave it up for ??? [1] this video
The “not all parts have to be performant, so you can make those parts clean” objection never sits well with me. And it’s not just the fact that clean code is presented as universal and this claim is only introduced after you complain that clean code has made your code less performant (Casey was remarkably polite in pointing this out and Bob was very gracious in concurring, both of which were a delight to read). The reason it doesn’t sit well is that, in practice, it seems like most products don’t know what needs to be fast and so developers end up making almost everything slow. Casey gives many examples but the one that sticks out most in my mind is the Visual Studio watch window (about 25 minutes into this video ). The watch window lets you pin variables you’re interested in and it will show you their current values as you step through the program’s execution. Invaluable for debugging. Visual Studio’s watch window is incredibly slow, to the point that it actually has a debounce so it will stop updating when you’re stepping quickly and only update once you’ve stopped quick-stepping. This seriously impacts its usefulness! To me, the watch window seems like it’s obviously one of those modules that needs to be running in milliseconds or less - but the company and/or the developers don’t see that, and shipped it slow (and presumably clean) instead. So in my mind, “write clean except where performance matters” comes with an almost fatal caveat, something like “you won’t know where pe
> Yep, a gross and incorrect one, invented only to advance an argument that doesn't match reality. Performance and ms-per-frame is still highly critical in AAA-land, I beg to differ it's not an incorrect one. AAA Titles (+ if I did play them): Destiny - Review say perf OK. Elden Ring(+) - Performance Ok on consoles on release it was a slideshow. It ran like garbage. Personally I think it's a clusterfuck GTA V(+) - Had a huge performance blunder. Released for n-thienth time. Good performance today for game that was released in 2013. FIFA/NFL/Sports game - Runs ok. It's the same game as year X-1 except with some tweaks (like microtransactions and ads). Call of Duty - Review while perf is Ok, it's not something Battlefield - They were Ok, they went too loose with optimization resulting in the shitfest that was 2042. They got punished for it. Fortnite - Sure stellar work from the guys making Unreal engine no complaints. According to revenue PUBG belongs on this list. PlayerUnknown’s Battlegrounds - Barely holding itself at the seams this game made mad money while being a buggy and lice infested mess. It Pokemon - It's Ok, but nothing to write home about. Resident Evil: Village(+) - Played it. It ran like shite. Had to crack it to get decent performance. Far Cry 6 - Ok performance, but essentially Farcry X-1. With more content. --------- From examples given, while performance is usually critical for online multiplayer shooters, it's not so much being faster as being less slow than