Post a Comment
The Community in question is people who use PowerShell and are willing to run a wildly pre-release version of v2. The CTP is a pre-alpha type release where interested parties can test it out and give feedback before the software features included are essentially finalized and they start the bug hunt which is beta testing. I can hardly wait to get my hot little hands on it.
Incidentally the last line in that brief was meant as a description of what was already in version 1 of PowerShell. Dunno much about the new features contemplated for v2 beyond built in remoting.
Probably beside the point to mention all this as it doesn't really continue with the '1337 h4xx0rz MS bashing. Don't mind me, I'll just chuckle knowingly on this side of the keyboard.
I can't find a directory, among my pretty big ones, where there is any perceivable delay at all from hitting enter and the output scrolling past. This is probably because (a) "dir" on Windows' cmd.exe is a built-in command, so it doesn't have to search the path for it or do any of that executable overhead; and (b) I was going to say it displays as it reads from disk, but it's not noticeably slower where I'm testing with /ON (which indicates sorting by name), so I guess it's mostly the overhead thing.
Cygwin ls on the same machine under the same conditions can vary wildly in speed, probably because of executable caching; but if you don't sneak up on it, and don't ask for full file attributes, it appears to be just as fast (from either cmd.exe or, for example, zsh in puttycyg)
Edited 2007-11-03 05:31
This is probably because (a) "dir" on Windows' cmd.exe is a built-in command, so it doesn't have to search the path for it or do any of that executable overhead
Cmdlets in PowerShell are in memory pieces of code. Once PowerShell's started, it doesn't need to look for it anywhere. What's creating the huge delays is probably that the respective Cmdlet creates a list of files and then creates a FileInfo object for each filename.



