Twitter and Visual Studio Rant

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]

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

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

> Which is why I find so ironic that many still think only languages like Assembly, C or C++ have a place in IoT on devices like ESP32. Short answer, Parkinson's law. When I browse the Web, open my Windows File Explorer, open Photoshop, open Visual Studio, open just a graphical application that needs GPU acceleration, or do whatever thing that should not be an issue, I find that Parkinson's law very much applies. [this video] [this video] [link] Wtf. Did you see how fast VS6 started on a machine from almost 20 years ago. Today I get depressed whenever I need to open Visual Studio, and I don't even know that I use any more functionality that wasn't available 20 years ago. Many many programmers (in my perception at least) are extremely dissatisfied with today's state of computing, and the reason why we got here is the popular opinion that we don't need to worry about performance. Nobody should optimize representations of Pi or count CPU cycles by default. That's not the point. But if you claim that Java is always fast enough for example, then I think we're having a strong disagreement. It's partly confirmation bias and being unaware of vast parts of the landscape, but it's also a fact, that I couldn't name you a complex GUI written in Java with satisfying ergonomics.

> Which software exactly is functionally the same yet consumes more resources? Can you give some specific examples? Here is one concrete example: visual studio startup and debugging. Source: [this video] Maybe I could start collecting examples. I never did because it is so obvious. I mean, have you never updated android/iOS/windows on the same hardware? Regarding the "exactly" part in you sentence. Why would more features equal less performance? The only possible reason I can see this happening, is if you have features that run in parallel. Otherwise it's just another callback/if etc. That is, something to be triggered by the user that should have imperceptible impact (slightly more pressure on the instruction cache) on the performance of other features.

> 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

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

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]