Twitter and Visual Studio Rant

> 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.

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]

> 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.

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

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

Reminds me of these videos from Casey Muratori: 30 million line problem - [LINK] Twitter and Visual Studio Rant - [VIDEO]

None of which can explain why launching an Explorer window takes a perceptible amount of time, or this: [VIDEO] , or any of thousands of similar atrocities of wasting everyone's computing resources and time to accomplish nothing of note.

You can achieve good memory footprints with Linux, just 2 or 3 years ago I was daily driving Arch linux with bspwm as a window manager, it used only 300 mb, for me is pretty darn good, but as soon as I opened my vscode with a JS project my ram usage was at 12gb. We have a lot of bloatware everywhere, that’s pretty sad. edit: This remind me a some rants from Casey Muratori about VS[0] and windows terminal[1] [0] [VIDEO] [1] [LINK]

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

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

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

Here's the video he's referencing of the 20-year-old computer where Visual Studio is instantaneous: [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] [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: [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.

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". [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 - [VIDEO] Or this one? Roger Clark developing Notepad in C++ on Windows 2000 and commenting how fast Visual Studio opens: [LINK]

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