Download : tabdir 320k zip
usage : tabdir [opts] [dir]
-v : view output after writing
-p : show progress of dir enumeration (with interactive keys)
-w# : set # of worker threads
-oN : output to name N [r:\tabdir.tab]
This new tabdir is built on Oodle so it has a multi-threaded dir lister for much greater speed. (*)
Also note to self : I fixed tabview so it works as a shell file association. I hit this all the time and always forget it : if something works on the command line but not as a shell association, it's probably because the shell passes you quotes around file names, so you need a little code to strip quotes from args.
Someday I'd like to write an even faster tabdir that reads the NTFS volume directory information directly, but chances are that will never happen.
One odd thing I've spotted with this tabdir is that the Windows SxS Assembly dirs take a ton of time to enumerate on my machine. I dunno if they're compressed or WTF the deal is with them (I pushed it on the todo stack to investigate), but they're like 10X slower than any other dir. (could just be the larger number of files in there; but I mean it's slow *per file*)
I never did this before because I didn't expect multi-threaded dir enumeration to be a big win; I thought it
would just cause seek thrashing, and if you're IO bound anyway then multi-threading can't help, can it? Well,
it turns out the Win32 dir enum functions have quite a lot of CPU overhead, so multi-threading does in fact help
a bit :
nworkers| elapsed time
1 | 12.327
2 | 10.450
3 | 9.710
4 | 9.130
(* = actually the big speed win was not multi-threading, it's that the old tabdir did something rather dumb in the file enum. It would enum all files, and then do GetInfo() on each one to get the file sizes. The new one just uses the file infos that are returned as part of the Win32 enumeration, which is massively faster).