I notice that tabdir defaults to writing to r:\tabdir.tab which seems... odd. It also doesn't give any error messages if (for some odd reason) you don't have an R: drive mounted. I hacked around this with subst, but defaulting to %temp% and adding an error message would help the out-of-box experience.
But, looks useful.
April 4, 2013 at 11:06 PM
Anonymous said...
I found this oddly hilarious. I've been running clockres more frequently lately so I noticed when my systems timer interval was dropped to 1 ms -- thus wasting power. I investigated with powercfg -energy. Guess who:
I'd never heard of anyone caring. In fact I did some tests at one point where I queried the timer interval *before* setting it, and I always found it was already 1 because some app had set.
Seems like an unnecessary headache to fight that. The whole idea that it's variable but global and apps get to set it is super broken, BTW.
I suspect that enumerating your entire disk affects battery more than the tbp(1) ;)
Certainly I agree in principal that things like casual games which might just sit running in the background while a user browses the web should be careful about not consuming excessive resources. Game developers can get stuck in this philosophy that they own the whole machine and get to brutalize it.
"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."
Apparently, SwiftSearch does something like this.
http://sourceforge.net/projects/swiftsearch/
(Not a recommendation; I've never used it)
April 6, 2013 at 1:43 PM
Anonymous said...
I agree that increasing the timer frequency while tabdir is running is not a problem, because it keeps the system busy anyway. However I would urge you to not routinely set the timer to 1 KHz at startup because for other programs it is a big deal. Some programs (Chrome, Starry Night, etc.) are on my kill list for when I'm running on battery because they increase the timer frequency unnecessarily.
Timer frequency is, of course, not the only thing that affects power draw, but burning ~0.3 W for no reason seems like a bad idea.
Yeah, totally agree with you that programs which sit idle need to minimize their resource usage.
March 30, 2014 at 12:55 PM
I made a fresh build of "tabdir" my
old
( old ) utility that does
a recursive dirlisting in tabbed-text format for "tabview".
Download : tabdir 320k zip
tabdir -?
usage : tabdir [opts] [dir]
options:
-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).
"04-04-13 - Tabdir"
9 Comments -
I notice that tabdir defaults to writing to r:\tabdir.tab which seems... odd. It also doesn't give any error messages if (for some odd reason) you don't have an R: drive mounted. I hacked around this with subst, but defaulting to %temp% and adding an error message would help the out-of-box experience.
But, looks useful.
April 4, 2013 at 11:06 PM
I found this oddly hilarious. I've been running clockres more frequently lately so I noticed when my systems timer interval was dropped to 1 ms -- thus wasting power. I investigated with powercfg -energy. Guess who:
Platform Timer Resolution:Outstanding Timer Request
A program or service has requested a timer resolution smaller than the platform maximum timer resolution.
Requested Period 10000
Requesting Process ID 11864
Requesting Process Path \Device\HarddiskVolume3\bin\tabdir.exe
How come tabdir is requesting a lower timer resolution? Is this intentional, or some odd side-effect?
April 4, 2013 at 11:11 PM
I always timeBeginPeriod(1) at startup.
I'd never heard of anyone caring. In fact I did some tests at one point where I queried the timer interval *before* setting it, and I always found it was already 1 because some app had set.
Seems like an unnecessary headache to fight that. The whole idea that it's variable but global and apps get to set it is super broken, BTW.
April 5, 2013 at 7:05 AM
Updated. Still defaults output to r:\ cuz that's what I like, but if that fails it writes to temp.
April 5, 2013 at 7:47 AM
timeBeginPeriod(1) runs down your laptop's battery.
Chrome is* careful to adjust it based on whether there are pending tasks that need it:
https://code.google.com/p/chromium/issues/detail?id=46531
It seems likely the users of tabdir are different than Chrome's though.
* Looking at the bug tracker, it seems to maybe have regressed since that point.
April 6, 2013 at 8:23 AM
I suspect that enumerating your entire disk affects battery more than the tbp(1) ;)
Certainly I agree in principal that things like casual games which might just sit running in the background while a user browses the web should be careful about not consuming excessive resources. Game developers can get stuck in this philosophy that they own the whole machine and get to brutalize it.
April 6, 2013 at 8:33 AM
"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."
Apparently, SwiftSearch does something like this.
http://sourceforge.net/projects/swiftsearch/
(Not a recommendation; I've never used it)
April 6, 2013 at 1:43 PM
I agree that increasing the timer frequency while tabdir is running is not a problem, because it keeps the system busy anyway. However I would urge you to not routinely set the timer to 1 KHz at startup because for other programs it is a big deal. Some programs (Chrome, Starry Night, etc.) are on my kill list for when I'm running on battery because they increase the timer frequency unnecessarily.
Timer frequency is, of course, not the only thing that affects power draw, but burning ~0.3 W for no reason seems like a bad idea.
My timer interval is currently 15.6 ms.
April 11, 2013 at 5:41 PM
Yeah, totally agree with you that programs which sit idle need to minimize their resource usage.
March 30, 2014 at 12:55 PM