6 ms·

so, I wonder if I'm suffering from selection bias because of these excellent articles I keep reading in randomascii. I keep reading these articles about terrib

so, I wonder if I'm suffering from selection bias because of these excellent articles I keep reading in randomascii. I keep reading these articles about terrible quadratic complexity for things on windows, it gives me the impression that performance on windows can be pretty bad, and frankly, I don't have the best opinion of windows. Is performance worse in general on windows? I haven't used it for a fair few years. Is it just generally a worse OS? I used to somewhat resent having to use windows when I needed to develop on it (developing for games consoles) but there were some nice parts (I have to say, visual studio is really nice as an integrated debugger, even if I prefer other editors). I'm trying to check my biases. Is windows actually a fairly poor OS nowadays? > If you are not on Windows – I’m very sorry. The writer on the article definitely seems to think that it's a nice one, despite the constant issues they run into. Is this just because they've used the system so long, and have developed such expertise with it, or there are things to love that I'm missing about it?

jstanley 6y ago
> If you are on Windows then make sure you are using symbol servers. If you are not on Windows – I’m very sorry. I thought this was a particularly bizarre take, given that in the very same post the author has lamented not having access to the source code of the program he is trying to debug. You can keep your symbol servers, I'll take the source code please.
- wtallis 6y ago
  I think the point is that the stuff on the symbol servers corresponds to the binaries used in the wild by the people who first encounter these issues. On Linux, you might run into the problem of a distro shipping stripped binaries, which means having the source code doesn't help much in parsing a stack or profiler trace. Instead, you need to track down the debug info for the binaries as compiled and shipped by that particular distro. Even in the best case, that will be more work than Microsoft's single-source symbol server.
jiggawatts 6y ago
For most users, most of the time, Windows performance is just fine. This is especially true on modern 64-bit hardware with SSDs when using the latest Windows 10 builds. In the past? It was a bit of a mixed bag. TCP performance and network latency in general was always worse on Windows than Linux, largely for silly reasons. Similarly, the 32-bit versions had a lot of fixed sized memory regions for things like file caching that were set in stone in the NT4 era and not changed until Windows Vista. Towards the end when all 32-bit machines had 4GB of memory, this made disk access unnecessarily slow. There are also design space differences between Linux and Windows. On Linux a process is very lightweight, basically a fat function call. On Windows the equivalent need is typically met by RPC calls to an already running process. Threads are cheap on Windows and threading was very well supported since the 1990s. On Linux, not as well, even now. For example, even NT4 and async scatter/gather IO that SQL Server used back in v7. I believe that Linux is still struggling with this. Conversely, Windows beats the pants off Linux in some areas, even now. Try using a Linux desktop with a flaky DNS server. Hooo-boy. Timeout city! On Windows this is almost unnoticeable, because it fails over to the secondary DNS server in milliseconds and caches all results as expected. Linux failover and caching seems to require a significant effort to set up by the users, for some mysterious reason. Similarly, Windows SMB v3 over RDMA is crazy fast. If you have the right NIC, you can flatline a 40 Gbps pipe with a single file copy. In the Windows Explorer GUI! No special tools needed. Copy, paste, and next thing you know you're doing 5 gigabytes per second. That takes real effort to match in Linux. Etc... Basically, everyone is used to the warts on their preferred system, and has learned to work around them. But when exposed to something unfamiliar, all the little issues seem to be always in the way.
- muststopmyths 6y ago
  > TCP performance and network latency in general was always worse on Windows I would disagree. Unless you're trying to write "cross-platform" network code using select and other POSIX-style interfaces, in my experience Windows with IOCP or RIO will beat any other user mode application TCP stack for I/O rates and latency. Vista's stack had latency issues in the beginning but Windows 8 with RIO was released a long time ago. Note I said "user mode application". Linux has easier kernel bypass and well-supported DPDK for applications that really need it. You obviously cannot beat that with user-mode code
hdjcktnr 6y ago
File system performance is arguably terrible on Windows, when working with thousands of files. Stuff like "npm install", large git operations are many times slower than doing the same operation in a linux virtual machine running on that same Windows. Hard to tell if it's Windows itself, or maybe npm/git not using the "proper ways" Other than that, Windows performance it just fine, and arguably smoother than a Linux desktop (no mouse freezing for example).
- xfer 6y ago
  Consider adding your code directory to exclusions list for windows defender, if you haven't done so already. File metadata related operations are slower on windows, so it definitely feels worse with git.
- brucedawson 6y ago
  Yep, file system performance is a continued source of frustration, most noticeable when using git. Using Windows Defender exclusions is necessary but not sufficient - it's still slow.
TacticalCoder 6y ago
> The writer on the article definitely seems to think that it's a nice one, despite the constant issues they run into. The Stockholm syndrome is a very real thing.
- brucedawson 6y ago
  It could be Stockholm syndrome for sure. I have not used Linux enough lately or OSX basically at all to know what they are like. I know the advantages and the warts of Windows very well, and I know neither for other operating systems. The "I'm very sorry" comment was meant to be strictly in relation to symbol servers where Windows is clearly ahead (although Linux may be making progress in this area).
  - mijoharas 6y ago
    first off, thanks for the article! I always enjoy reading them. Secondly, I think it's a very good point you raised. Sad to see the situation hasn't progressed much in the linux world, as reading about Microsoft's symbol servers, they seem incredibly useful!
brucedawson 6y ago
On a day-to-day basis the only times that Windows feels slow are: 1) Git operations. These run faster on Linux and I waste some measurable number of seconds/minutes each due to this slowdown, presumably due to slower file operations. 2) Start bar menus. I frequently right-click an icon on the task bar and even after they fixed the problem I reported in 2019 there is still a noticeable delay. If I then have to right-click on the application name to bring up the sub-menu then there is a secondary delay which is even longer. These delays happen even if I repeatedly right-click on the same icon. I find it bizarre that "waiting for a menu" is a thing in 2021. Blog post is here: https://randomascii.wordpress.com/2019/09/08/taskbar-latency-and-kernel-calls/ https://randomascii.wordpress.com/2019/09/08/taskbar-latency...

jstanley 6y ago

> If you are on Windows then make sure you are using symbol servers. If you are not on Windows – I’m very sorry. I thought this was a particularly bizarre take, given that in the very same post the author has lamented not having access to the source code of the program he is trying to debug. You can keep your symbol servers, I'll take the source code please.

wtallis 6y ago
I think the point is that the stuff on the symbol servers corresponds to the binaries used in the wild by the people who first encounter these issues. On Linux, you might run into the problem of a distro shipping stripped binaries, which means having the source code doesn't help much in parsing a stack or profiler trace. Instead, you need to track down the debug info for the binaries as compiled and shipped by that particular distro. Even in the best case, that will be more work than Microsoft's single-source symbol server.

jiggawatts 6y ago

For most users, most of the time, Windows performance is just fine. This is especially true on modern 64-bit hardware with SSDs when using the latest Windows 10 builds. In the past? It was a bit of a mixed bag. TCP performance and network latency in general was always worse on Windows than Linux, largely for silly reasons. Similarly, the 32-bit versions had a lot of fixed sized memory regions for things like file caching that were set in stone in the NT4 era and not changed until Windows Vista. Towards the end when all 32-bit machines had 4GB of memory, this made disk access unnecessarily slow. There are also design space differences between Linux and Windows. On Linux a process is very lightweight, basically a fat function call. On Windows the equivalent need is typically met by RPC calls to an already running process. Threads are cheap on Windows and threading was very well supported since the 1990s. On Linux, not as well, even now. For example, even NT4 and async scatter/gather IO that SQL Server used back in v7. I believe that Linux is still struggling with this. Conversely, Windows beats the pants off Linux in some areas, even now. Try using a Linux desktop with a flaky DNS server. Hooo-boy. Timeout city! On Windows this is almost unnoticeable, because it fails over to the secondary DNS server in milliseconds and caches all results as expected. Linux failover and caching seems to require a significant effort to set up by the users, for some mysterious reason. Similarly, Windows SMB v3 over RDMA is crazy fast. If you have the right NIC, you can flatline a 40 Gbps pipe with a single file copy. In the Windows Explorer GUI! No special tools needed. Copy, paste, and next thing you know you're doing 5 gigabytes per second. That takes real effort to match in Linux. Etc... Basically, everyone is used to the warts on their preferred system, and has learned to work around them. But when exposed to something unfamiliar, all the little issues seem to be always in the way.

muststopmyths 6y ago
> TCP performance and network latency in general was always worse on Windows I would disagree. Unless you're trying to write "cross-platform" network code using select and other POSIX-style interfaces, in my experience Windows with IOCP or RIO will beat any other user mode application TCP stack for I/O rates and latency. Vista's stack had latency issues in the beginning but Windows 8 with RIO was released a long time ago. Note I said "user mode application". Linux has easier kernel bypass and well-supported DPDK for applications that really need it. You obviously cannot beat that with user-mode code

hdjcktnr 6y ago

File system performance is arguably terrible on Windows, when working with thousands of files. Stuff like "npm install", large git operations are many times slower than doing the same operation in a linux virtual machine running on that same Windows. Hard to tell if it's Windows itself, or maybe npm/git not using the "proper ways" Other than that, Windows performance it just fine, and arguably smoother than a Linux desktop (no mouse freezing for example).

xfer 6y ago
Consider adding your code directory to exclusions list for windows defender, if you haven't done so already. File metadata related operations are slower on windows, so it definitely feels worse with git.
brucedawson 6y ago
Yep, file system performance is a continued source of frustration, most noticeable when using git. Using Windows Defender exclusions is necessary but not sufficient - it's still slow.

TacticalCoder 6y ago

> The writer on the article definitely seems to think that it's a nice one, despite the constant issues they run into. The Stockholm syndrome is a very real thing.

brucedawson 6y ago
It could be Stockholm syndrome for sure. I have not used Linux enough lately or OSX basically at all to know what they are like. I know the advantages and the warts of Windows very well, and I know neither for other operating systems. The "I'm very sorry" comment was meant to be strictly in relation to symbol servers where Windows is clearly ahead (although Linux may be making progress in this area).
- mijoharas 6y ago
  first off, thanks for the article! I always enjoy reading them. Secondly, I think it's a very good point you raised. Sad to see the situation hasn't progressed much in the linux world, as reading about Microsoft's symbol servers, they seem incredibly useful!

brucedawson 6y ago

On a day-to-day basis the only times that Windows feels slow are: 1) Git operations. These run faster on Linux and I waste some measurable number of seconds/minutes each due to this slowdown, presumably due to slower file operations. 2) Start bar menus. I frequently right-click an icon on the task bar and even after they fixed the problem I reported in 2019 there is still a noticeable delay. If I then have to right-click on the application name to bring up the sub-menu then there is a secondary delay which is even longer. These delays happen even if I repeatedly right-click on the same icon. I find it bizarre that "waiting for a menu" is a thing in 2021. Blog post is here: https://randomascii.wordpress.com/2019/09/08/taskbar-latency-and-kernel-calls/ https://randomascii.wordpress.com/2019/09/08/taskbar-latency...