Linked by Thom Holwerda on Sat 11th May 2013 21:41 UTC
Windows "Windows is indeed slower than other operating systems in many scenarios, and the gap is worsening." That's one way to start an insider explanation of why Windows' performance isn't up to snuff. Written by someone who actually contributes code to the Windows NT kernel, the comment on Hacker News, later deleted but reposted with permission on Marc Bevand's blog, paints a very dreary picture of the state of Windows development. The root issue? Think of how Linux is developed, and you'll know the answer.
Permalink for comment 561283
To read all comments associated with this story, please click here.
Problems in userland
by jhowie on Sun 12th May 2013 22:57 UTC
jhowie
Member since:
2013-05-12

I can speak from experience when I submitted code for inclusion in what was then known as the Windows Resource Kit. Without naming the utility, what I developed was tool that had two threads - a reader and a writer. The reader thread read data from the filesystem and stored data in a linked list, and the writer thread would take data from the linked list and write it out to the filesystem. All very elegant, tested to death, and CS 101, it was rejected because I did not use a named pipe between the threads. I pointed out that, at the time, calls to named pipes caused context switches and adversely impacted performance. The feedback I received was "what is a context switch?". I explained that switching from user mode to kernel mode in a thread had a performance impact. No-one cared. They had their way of doing things and refused to even look at others. I also learned that some of the review team did not understand how linked lists worked and could not be assured there were no bugs in the code because they could not understand it. The utility that eventually shipped used a named pipe, and was significantly slower than the one I originally developed. It is now part of Windows. Needless to say, I use my own version (still).

Reply Score: 3