If you haven't tried the File Explorer in W11 24H2 it turned into a complete joke overnight now.
Slow as a dog and will often not render after all, compared to how it would act for decades up until less than a year ago.
It's a new defect in relation to the video drivers, badly incompatible with the default Microsoft Standard Display Driver, so what can you say?
I would expect that's an indication that XYplorer is a much more advanced, well-developed and mature alternative not relying on flaky emerging APIs that have too few decades of reliability to compare.
As much as I like C# the language, I honestly think that it and .NET are fundamentally flawed when it comes to performance.
Native Windows apps just never seem load that fast or work that great. It’s kind of crazy how much better the basic OS apps feel in macOS compared to Windows.
I wish Microsoft would have gone in a direction more similar to Apple, with an AOT compilation and reference counting.
JIT and garbage collection sound great in theory, but in practice I’ve found them both to be loaded with footguns that more than eliminate any benefits. At least with .NET, that is.
Most applications that ship with Windows are not written in C#/.NET. Microsoft tried to rewrite everything this way around Vista, but they failed hard due to stability and performance issues. In Windows 11/Server 2025, the only things written in .NET are administrative tools, like most MMC snap-ins (e.g. Event Viewer), Virtual Machine Connection, or Server Manager.
To be fair, .NET back then was just not where it is today. And the C++ faction within Microsoft did not help that either.
But a lot of people are completely out of touch, thinking something along the lines of "Clearly Golang is managed by YouTube and Google Search teams" except about .NET whenever complaining about whatever happens to Windows nowadays.
I've built many apps using C#/Winforms and the runtime's performance was never an issue.
In my experience, main performance killers are:
- calling blocking functions on the UI thread
- N+1 problem
And there's nothing specific to C# about it. .NET garbage collection becomes an issue only when you allocate lots of objects per second (100k or millions), and very few UI apps do that. If there's perceived sluggishness, I doubt it's the runtime.
> Native Windows apps just never seem load that fast or work that great.
On NT, process creation is very slow compared to most (all modern?) other operating systems, where-as thread creation is near-instant.
Not sure what you mean by 'work that great'.
> JIT and garbage collection sound great in theory, but in practice I’ve found them both to be loaded with footguns that more than eliminate any benefits.
I can't think of a single C# Console, Web, or WPF app I've created where I have to explicitly concern myself with JIT or GC. That doesn't mean they're not out there (games? maybe? Fez? Stardew Valley?), but I think you'd find one calling explicit GC methods somewhat rare, or being concerned with how long an app takes to JIT.
I used to deal with SharePoint Server quite a bit which is _slow_ to start due to JIT, but I didn't care because I'd just have an uptime monitor app fetch a page or few on the front end to make sure it JITs before (re)adding it to the load balancer.
Do you have some examples of large and complex C# applications with really good performance?
I’m hard pressed to think of any Microsoft software at all that I think feels really nice. Except for VSCode, which is of course built on Electron and not .NET.
The only thing that comes to mind is Paint.NET, which doesn’t seem like all that big of an application. It’s very nicely done, but I think it’s only got like a single dev working on it, so couldn’t be that big.
> Do you have some examples of large and complex C# applications with really good performance?
Most of them. An implementation would have to go out of its way to make itself perform poorly if it is built on top of, say, .NET 8.
Have you heard of Ryujinx? Or Nethermind? Or Garnet? Or have you seen that .NET's Regex engine, written in pure C#, is the third fastest in the world after Intel's Hyperscan and Rust's Regex crate?
Fair enough, maybe my perceptions of .NET performance are mostly based on old versions of .NET without all the tiered compilation and other features to make JIT warmup less of an issue.
We are only just now wrapping up the conversion at work to .NET 8 from 4.8, so it will be interesting to see the performance numbers once that is complete.
Our .NET application has millions of lines of code, so JIT compilation time in particular in the old .NET could be very painful.
At my previous employer, moving from .NET Framework 4.6.1 to .NET Core 3.1 resulted in response latency of one of the particularly heavy requests going from ~2s to ~300ms :)
The difference between 4.8 and 8 can easily be tenfold, depending on the workload and bottlenecks (if it's a slow DB query - EF Core might compile it to a more efficient variant in, say, EFC 8, but if it's linear scan - not much can be done).
That's specifically an example of an application that I think is slow. It's slow to load and often slow to respond. The support for Git has to be amongst the slowest of any professional application in the world. But I'm pretty sure it has a deeply flawed architecture compared to VSCode.
It's written in C++ and .NET Framework. VS is mostly an exception anyway. I much prefer to use VS Code + Rider instead. Your comments leave me with impression that you are not interested in understanding the performance profile of .NET and are looking to engage in a language flamewar instead.
Edit: I stand corrected, based on reply in a sibling comment most of the perception stems from how .NET Framework works. Understandable.
I don’t have a lot of experience with this, but that’s mainly because there’s no way to compile my company’s application with Native AOT. At least not without a significant amount of work.
This is because there are many limitations in what can be compiled this way, and most C# applications and libraries were never built with such limitations in mind.
AFAIK, the limitations are just some (not all) reflection API is missing, and trimming can cause problems. That’s pretty much about it. Obviously it’s a problem if you need those, but I wouldn’t call it “many limitations”.
It's honestly blazingly fast in comparison to Windows Explorer on Windows 11.