Someone posted the question on StackOverflow and it got closed as "not constructive". Is there a way to browse the "not constructive" questions on SO? They seem to be all the best ones.
Interesting. I wonder how many "Linux-bashing threads" (that contained valid questions which made perfect sense) were closed as not constructive.
No need to invent a new conspiracy - closing and reopening happens regularly and for a lot of reasons/subjects.
Just - add a vote to reopen it, if you feel that the question is relevant. I just did.
Interestingly enough Joel Spolsky mentioned something related to the directory listing problem more than 10 years ago. See: http://www.joelonsoftware.com/articles/fog0000000319.html In Joel's opinion it is an algorithm problem. He thinks that there is an O(n^2) algorithm in there somewhere causing trouble. And since one does not notice the O(n^2) unless there are hundreds of files in a directory it has not been fixed…
I just wish the "many eyes" phenomenon worked equally well for device drivers.
I suspect it has something to do with NTFS updating access times by default. So every time you do anything with a file, it gets its access time updated (not modification time, access time). I don't have windows to test on, but you could try the suggestions [1][2] below. [1] http://msdn.microsoft.com/en-us/library/ms940846(v=winembedd... [2] http://oreilly.com/pub/a/windows/2005/02/08/NTFS_Hacks.html (#8)
But most Linux distros do this by default as well. You have to mount with noatime to get rid of it.
In fact nowadays most (all?) linux filesystems use relatime as default, which carries most of the advantages of both atime and noatime. See http://kerneltrap.org/node/14148
I don't know if something similar exists under windows (I suppose it doesn't).
I don't know this poster, but I am pretty familiar with the problem he's encountering, as I am the person most responsible for the Chrome build for Linux. I (and others) have put a lot of effort into making the Linux Chrome build fast. Some examples are multiple new implementations of the build system ( http://neugierig.org/software/chromium/notes/2011/02/ninja.h... ), experimentation with the gold linker (e.g. measu…
tldr; no one at Google uses windows, a lot of time was spent optimizing the linux build, zero time was spent optimizing the windows builds.
I don't know this poster, but I am pretty familiar with the problem he's encountering, as I am the person most responsible for the Chrome build for Linux. I (and others) have put a lot of effort into making the Linux Chrome build fast. Some examples are multiple new implementations of the build system ( http://neugierig.org/software/chromium/notes/2011/02/ninja.h... ), experimentation with the gold linker (e.g. measu…
What is preventing you from using MinGW? That way, you could use the GNU toolchain (Make, GCC, Binutils etc.) and still have full access to the Win32 API. You could reuse almost all of your Unix build scripts, and the rest boils usually down to making your scripts aware of different file extensions ( .exe/ .dll instead of / .so). Even better, you can do cross compiling with MinGW . So if your toolchain dosn't perform…
VC++ generates significantly better code than GCC. Enough so that performance-minded projects usually wouldn't consider MinGW/GCC for Windows code.
Wow, so if you want to test file system speeds, you do it by listing files - I know this just an example, but perhaps it has something to do with the speed of the terminal ? There are a plethora of disk benchmarking tools - I doubt that they consistently show 40x differences. Hooves -> horses, and all that.
Maybe I'm misunderstanding (or he's since changed his post), but: dir /s > c:\list.txt is piping it into a file. Where does the speed of the terminal affect that (in any significant fashion)? I know what you're getting at - tar --verbose can slow things down for me by sometimes a factor of 2 (for huge tarballs), but I don't think it's an issue in this situation.
Yes, I saw the redirection. But "dir" is an built-in command in the Windows shell; is the speed of that command a benchmark-able number? Is the point to compare the speed of "ls" vs "dir", or the underlying OS/file-systems (i.e., posix vs. win32 /Ext3 vs. NTFS)? If someone tells me that "dir" is slow, I'd agree -- but that -- in itself -- doesn't imply that the filesystem is slow.
Wow, so if you want to test file system speeds, you do it by listing files - I know this just an example, but perhaps it has something to do with the speed of the terminal ? There are a plethora of disk benchmarking tools - I doubt that they consistently show 40x differences. Hooves -> horses, and all that.
I suspect it has something to do with NTFS updating access times by default. So every time you do anything with a file, it gets its access time updated (not modification time, access time). I don't have windows to test on, but you could try the suggestions [1][2] below. [1] http://msdn.microsoft.com/en-us/library/ms940846(v=winembedd... [2] http://oreilly.com/pub/a/windows/2005/02/08/NTFS_Hacks.html (#8)
Mac OS X does appear to mount with atime but I happened to use this:
Interestingly enough Joel Spolsky mentioned something related to the directory listing problem more than 10 years ago. See: http://www.joelonsoftware.com/articles/fog0000000319.html In Joel's opinion it is an algorithm problem. He thinks that there is an O(n^2) algorithm in there somewhere causing trouble. And since one does not notice the O(n^2) unless there are hundreds of files in a directory it has not been fixed…
I just wish the "many eyes" phenomenon worked equally well for device drivers.
Unfortunately most of the drivers are in the long tail of unpopular devices. This results in greatly reducing the average number of eyes per driver.
This has a double effect: there are less developers who can attempt to fix problems with a driver and second, the incentive seems smaller - make general I/O 0.5% faster and you're a hero of the public, fix a critical problem in an unpopular device driver and maybe 1 person notices.
Interestingly enough Joel Spolsky mentioned something related to the directory listing problem more than 10 years ago. See: http://www.joelonsoftware.com/articles/fog0000000319.html In Joel's opinion it is an algorithm problem. He thinks that there is an O(n^2) algorithm in there somewhere causing trouble. And since one does not notice the O(n^2) unless there are hundreds of files in a directory it has not been fixed…
Along the same line, I've never understood Windows' propensity to swap out the kernel. I might have tons of free memory and half my kernel is swapped out. In fact, I've never figured out how to get it not swapped out, no matter how much memory I put in.
You could try this (from an elevated command-prompt), but the general consensus is that it has a small (if any) effect: