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.
True, I agree it's not necessarily a good way to test the filesystem, but it's only the shell that's being hit, nothing really to do with the terminal.
I pointed it out mainly because terminals can have a significant impact on performance, because dumping millions of lines a second isn't their intended purpose,[1] whilst the shell can be reasonably expected to do that.
Having it entirely as a shell built-in possibly actually better than the equivalent '/bin/ls > somefile' since it doesn't need to context switch back and forth as the stdout buffer fills up and the shell has to write it.
[1] I recall there being a Gentoo-related thread about why "Gentoo-TV" -- having the output of gcc scroll past as your background with a transparent xterm -- was actually slowing down package builds significantly.
If it's unreasonable to assume a 30-year old command extending directly back to MS-DOS 1.0 has never had anybody once take a look at making sure it isn't unreasonably slow, well, I think there's some reasonable conclusions we can draw from that with regards to performance on Microsoft products.
