[ClickedUp]

I already gave two examples 1) large-scale WinForms app with third-party controls and libraries and 2) Interop with FS kernel driver under heavy load

We were told to benchmark the performance on several computers using different hardware. In example 1 we calculated ~30% worse performance (worst case scenario!). In example 2 we had micro stuttering and system wide freeze (requiring reboot).

Again, in example 2, are we supposed to accept our customer computer freezing under load? In a high security, sensitive environment? You must be joking! Instead we delivered a solid product which do not freeze the system and we got great feedback. What's considered 'obsolete' is irrelevant to us. The word means nothing. Our benchmarks are of the highest importance.

Let me try again on monday though, I can reproduce the results then. Your claim piqued my curiosity, but I think you underestimate the specific requirements in which we work. Perhaps they've fixed something since last time we tried. I'm certainly willing to try again.

[exceptione]

Would be interesting to learn more. It seems like you know your stuff well, but could it be that your ported code doesn't do things like it should be done in modern .net?

Like using the apis that fully utilize spans. Also, I have the feeling (but nothing tangible) that old .net and .net core do behave differently wrt async stuff too.

[ClickedUp]

> could it be that your ported code doesn't do things like it should be done in modern .net?

I'm actually curious myself after this discussion. I didn't port it, my coworker did it and I'd have to ask him. I did take part in the benchmark though and watched all the deadlocks happening.

Found this old screenshot of our internal FS driver debugging tool - to give you an idea of what I mean by needing high performance: https://postimg.cc/mc6YQFbC

24,654 filesystem events in C:\Windows\ in just 1 minute and 30 seconds on idle. 814 read operations (36,7MB) + 948 write operations (66,9MB). Now imagine this system-wide (not just the Windows dir) under heavier load. This is where modern .NET could not keep up leading to the aforementioned deadlocks.

Sorry that I can't provide more specific info at this time. I can find out more on Monday.

[exceptione]

Interesting, that is a good load test indeed. If it turns out to be a regression in .net core, it would certainly make sense to file a bug on github.

[neonsunset]

If there is an issue, chances are it's in the for-new-.NET implementation of WinForms. Any regressions in the GC or CoreLib themselves are definitely not expected and can be submitted as issues to be fixed.

There can be latency differences in edge cases of interaction between threadpool used by specific version and Overlapped IO on Windows, but that's likely about all there can be.

It's important to note that .NET Core 3.1 -> .NET 5 -> 6 -> 7 -> 8 is a huge difference in compiler and corelib internals (less so in GC, with major steps in 6, 7 and 8 in regards to regions and now DATAS), so an issue that could have existed in one of the previous versions is likely to be fixed by now.