As far as I know, Windows uses a multilevel feedback queue, so O(n²) would be surprising. The one issue that pops up with the Windows scheduler is when you have plenty of processes doing tiny little bits of IO instead of one huge slab of it.

Could you count it as a performance issue in the kernel ? Maybe. But really, you're mostly hitting an issue in what it's built to do. Windows really likes two things:

* don't spawn subprocesses

* please do your I/O in one huge batch and thank you.

The average Windows machine will barely have 100 processes running. I have 184 right now, and I run a lot of crap. This goes directly contrary to the philosophy of many UNIX programs: create a shitload of processes, fork everywhere, and write tiny files all the time.

I wouldn't complain about a hammer not working well if I'm using the handle to nail things. Sure, it would be nice if it also worked there, but it's not exactly made for that either, and for good reason. POSIX fork() being such a can of worms is half the reason that WSL1 was abandoned. Windows does not have the internal machinery to do that, because it wasn't built for that.