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] [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 [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. [VIDEO] [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: [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.

Tried Visual Studio 22 Preview. It couldn't run a debugger because "property program isn't defined". Apparently you need to specify some launch.json file god knows where, and god knows why. VSCode kinda works (but also creates a launch.json file somewhere). Rider just works. If it creates something somewhere, I couldn't care less (as I couldn't care less for any other IntelliJ product which tend to just work). Also. Obligatory rant by Casey Muratori on Visual Studio: [VIDEO]

It would be fine but it is slow. Watch window refreshes and responds to expanding trees like it is traversing dozens of gigabytes on every single action. (if you enjoy watching rants there's one: [VIDEO] )

> 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