> No multi-threading. A pity. But for a file manager not that important.
It's honestly blazingly fast in comparison to Windows Explorer on Windows 11.
It's honestly blazingly fast in comparison to Windows Explorer on Windows 11.
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.
https://answers.microsoft.com/en-us/msoffice/forum/all/micro...
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.
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.
and in context to the thread files-community/files is great and open-source and .NET * https://files.community/ (its actually 96% .net and 3.1% c++)
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?
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.
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).
Edit: I stand corrected, based on reply in a sibling comment most of the perception stems from how .NET Framework works. Understandable.
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.
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.
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.
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.