Twitter and Visual Studio Rant

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

We've gotten more pixels and bytes and flops, that's it. We haven't got more battery life, or faster computers, which is strange because they have orders of magnitude more flops in them. Casey Muratori showing off the speed of visual studio 6 on a Pentium something after ranting about it: Jump to 36:08 in ▶ this video

> "I remember seeing a video on here where someone actually booted up a computer from the 2000's and showed how snappy everything was, including Visual Studio" Was it this one? Casey Muratori ranting about Visual Studio Debugger slowness, and he shows a video of Visual Studio opening and debugging faster on a single core Pentium 4 from 20 years earlier - ▶ this video Or this one? Roger Clark developing Notepad in C++ on Windows 2000 and commenting how fast Visual Studio opens: link

I think you're right, maybe the disconnect is UI slowness? I am annoyed at the startup time of programs that I keep closed and only open infrequently (Discord is one of those, the update loop takes a buttload of time because I don't use it daily), but I'm not annoyed when something I keep open takes 1-10s to open. But when I think of getting annoyed it's almost always because an action I'm doing takes too long. I grew up in an era with worse computers than we have today, but clicking a new list was perceptibly instant- it was like the computer was waiting for the screen to catch up. Today, it feels like the computer chugs to show you what you've clicked on. This is especially true with universal software, like chat programs, that everyone in an org is using. I think Casey Muratori's point about the watch window in visual studio is the right one. The watch window used to be instant, but someone added an artificial delay to start processing so that the CPU wouldn't work when stepping fast through the code. The result is that, well, you gotta wait for the watch window to update... Which "feels bad". ▶ this video

> He has led a generation of impressionable programmers to believe that we in some dark age of software, when that statement couldn't be further from the truth. Have you actually used modern software? There's a great rant about Visual Studio debugger which in recent versions cannot even update debugged values as you step through the program unlike its predecessors: ▶ this video And this is professional software. There's state of personal software is worse. Most programs cannot show a page of text with a few images without consuming gigabytes of RAM and not-insignificant percentages of CPU.

Here's the video he's referencing of the 20-year-old computer where Visual Studio is instantaneous: ▶ this video

No, math is major part of writing good code, but when was the last time you've seen somebody put effort into writing O(n) algorithm? 99% of programming is "import sort from sort; sort.sortThisReallyQuick". Programming is mostly writing code that just compiles and eventually gives correct results (and has bugs). You can do a lot of programming just buy copy-pasting results from stackoverflow. link link ▶ this video

This reminds me of the famous Visual Studio rant by Casey Muratori ▶ this video And the hundreds (if not thousands :D) of rants by Jon Blow saying how contemporary software performance sucks

Casey ranting about how slow visual studio is and compares it to RemedyBG that uses Dear Imgui (an implementation of Immediate mode GUI). ▶ 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