| 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
https://www.youtube.com/watch?v=GC-0tCy4P1U How fast should an unoptimized terminal run?
https://www.youtube.com/watch?v=hxM8QmyZXtg 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 like Defender will pause execution until the entire file is checked. This is often even slower than the hash check. The caching of this is poor to non-existent in practice. - The Desktop Window Manager (DWM) performs several layers of buffering and swapping before an update gets to the screen. This has improved in very recent builds of Windows 11 but still has some overhead. An effective end-user workaround is to use a high refresh rate monitor such as the new 240 Hz OLEDs. There's a good online rant about it that can be summarised as "only Apple cares about this": https://danluu.com/input-lag/ - Heavyweight dependencies. Modern GUI toolkits like WinUI drag in half of all source code ever written by the human race if you look at them wrong. The Calculator app was taking 10s of seconds to start for some people (ultrabooks on battery) because it was loading crazy stuff like the "Windows 10 Hello for Business account recovery helper"! Why!? Because nothing is shared any more, every process loads its own dependencies... such as: HTTP client, which requires HTTP proxy support, which requires HTTP proxy auth, which requires Windows Auth, which includes Windows 10 Hello for Business passwordless auth, which requires... account recovery GUIs. For a calculator app. And the terminal. PowerShell. CLI tools in general. Etc... Yes, it's nuts. (Keep in mind each dependency must be loaded in full, hashed, signature checked, and scanned for malware!) - Telemetry. Every team says they do it efficiently, but only after customer complaints pile up. Some teams never learn, because it's fast for them, either because they know the secret code to turn it off, or because they're 1ms away from the telemetry collection endpoint. Intel for example (a hardware company!) has multiple telemetry tools force-installed with their drivers that spend > 10 minutes(!!) of CPU time daily on my laptop. I have to go and use NTFS ACLs to block execute permissions on those things because it "repairs" itself more aggressively than Bonzi Buddy. NVIDIA injects their telemetry into third-party processes, so about 20% of the startup time of the built-in Calculator App is NVIDIA telemetry. It's not a game! It just happens to use DirectX for graphing... so NVIDIA has to know about it. Etc... Microsoft themselves are the #1 worst offender. At one point, Office + Windows had 220 separate telemetry services or endpoints that I had to track down and disable (for a secure VDI project). PS: You know it's bad when a vendor starts releasing workarounds as a feature for the mis-features of their own product. The new Windows 11 "Dev Drive"[2] exists only as a workaround for bypassing the massive overheads of Window Defender. You would naively think that simply excluding a folder from Defender would have the same effect. Hah! No. Even the IntelliJ IDEA devs got fooled by this, their IDE has a feature[3] to exclude project folders form real time A/V scanning. This does nothing in Windows 11! All files are always scanned by Defender, even if a third-party anti-virus is installed. This behaviour is the same even on Windows Server, which is one of the main reasons that Azure DevOps build pipelines are something like 4x slower on Windows than on Linux. [4] [1] To be fair, most software companies are exactly the same. The industry as a whole has an allergy to performance optimisation, and regularly ships billion-dollar products with performance issues in them that would blow your mind. Think of how slow Jira is, or this doozy: https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times... [2] https://learn.microsoft.com/en-us/windows/dev-drive/ [3] https://intellij-support.jetbrains.com/hc/en-us/articles/360... [4] https://github.com/microsoft/azure-pipelines-agent/issues/44... |
Any more info on this? I now want to start looking into blocking these myself.
Thanks for the well written and informative post, I enjoyed reading it!