Hey, just wanted to let you know I haven't forgotten this thread
Finally got around to setting up the testbox again, so it should be ready for some... testing
. Might install a bit more software on it, just to have a few more files - the more the merrier. Did end up with a Raptor disk in it, though... pondering whether I should use a somewhat slower disk, but I guess I'll run some tests first. Hopefully during the coming week
I've tried running few cold-cache test and got numbers that are wildly different - from 131 seconds to 70 to 24. This is on a box that was shutdown, then powered on (with network connection disabled, with Windows Search and Windows Update services disabled, virtually no active tasks in the Task Manager and no resident antivirus/malware apps... so theoretically there's nothing that would actively populate disk index cache on boot). I will see what I've missed in a bit and re-run the tests.-apankrat
Sounds weird that you got such discrepancies - did you manage to make it somewhat reliable? Obviously there's going to be some fluctuation, but even 74 vs 24 seconds sound... interesting.
How are you doing the threading? Threadpool of workers that fetch a path from a queue, and while processing a path add found directories to the queue and "do whatever" with files? (Guess it could be somewhat difficult controlling breadth vs depth scanning reliably that way?) Or a different level of granularity?
With regards to getting 3x speed up on a warm cache - what's not to like? Arguably, this is the use case for real-time backups, with an operational profile consisting largely of frequent scans of small number of selected locations.-apankrat
Oh, it's not that it's not something to like, I was just thinking that as a
user, the absolute time difference isn't that big - and it will be dwarfed by syncing even a few files. (I'm pretty sensitive to timing myself, so it's something I might notice - but I'm thinking regular users here).
As a programmer, I think it's a cool achivement, though... and it wasn't something I had expected - guess I should revisit that old benchmark code
. And I can't see much reason not to do the threading, at least when keeping the number of threads sane. I pondered a bit about the whole thing; there's some increase in CPU usage and thus speedstep, power consumption and heat (and potential noise from CPU fan), but I don't think any of those are realistic concerns, given the short running time.
Then there's additional memory consumption because of threads - but when sticking with a sane number of threads, that shouldn't be a problem either, neither for user- nor kernelmode memory.
So I don't see a reason to
not do the threading, with the data given so far. And the 1.5x cold speedup is
nice, hope I can duplicate that on my testbox!
Recent Posts
), that article seems to have totally forgotten to mention the parents.
