forbin

SuperFast: Thanks for the support and the feedback! Yes, this is the kind of thing that I had envisioned as well, though I suspect that the folks at Piriform have more time and expertise than we do (even though I have been a systems-level programmer in my previous job incarnations) --- which would hopefully enable them to try a few variations on your scheme to determine what would do the most good. For example, one might be able to analyze the registry and certain folder locations (such as %SystemRoot%\System32\Drivers\) and look at files by type (.exe, .dll, .sys, .vxd, etc.) and by creation/modification/access date and put together a pretty clear picture of what files are "system" files or "frequently accessed executable files" as opposed to other types of files. I'd rather not attempt to artificially constrain the developers in trying to request a very specific layout. However, it just occurs to me that these two paragraphs are probably more to the benefit of other users than to the Piriform developers; the developers are smart and knowledgeable enough to read "eliminate having to hop across so many User Files to [access] the System Files" and figure out what it is that we really want. regards, --- forbin

Defraggler has the ability to run at normal priority, or at "background" priority. (In windows-speak, is that "below normal?" Or is it "low?") A couple of competing products also have the ability to run at higher than normal priority. This has several advantages. It not only allows the defragmentation to complete more quickly, it also appears to allow the defragger to do a better job. (My guess is, even if the user shuts down as many programs and services as possible before starting, and even if the defragger tries to use appropriate windows API calls to get windows to cooperate... the priority elevation still lets the defragger preempt other tasks more often so that things get defragged before something else can interfere.) So, is there any way we could get a "run at high priority" setting for Defraggler? Thanks! -- forbin

Sorry to duplicate previous topics, but none of them have had any activity for at least five months. Is Piriform considering adding the option to move the system files to the fastest part of the disk? Or has the idea been relegated to the dust bin? Currently, I'm having to use 2 different defrag programs to achieve (nearly) what I want! I run Defraggler and a not-to-be-named-competitor (which I will call NTBN for the purposes of this post). The NTBN defragger can move the system files, but it cannot put the really large files at the opposite end of the disk. What it can do is to completely ignore files larger than a threshold size. So I'm forced to run Defraggler (which I vastly prefer) to achieve "initial" defragmentation and move the big files out of the way... then I run NTBN, having it skip these large files, just so it can get the system files where I want them. My system run noticeably faster than when I was only running Defraggler. Unfortunately, I didn't benchmark anything and now there's probably no point in trying to do it on my already-optimized machine. It is probably a safe assumption, though, that if Piriform added the feature to Defraggler, they could do a better job than "the other guys," and the whole process would take less time since it would be accomplished in the same single defragmentation pass. [if someone wanted to try to collect benchmarks, I could give you the details of how I'm running the two pieces of software. Does anyone have a really nastily fragmented old disk they could use as a benchmarking platform? We'd need to collect baseline measurements of the disk as-is, then run Defraggler with the same settings I use and benchmark that as "without the system move feature". Then we'd run "NTBN" with my settings, and benchmark the disk performance after that as "probable performance using the proposed feature plus the 'move big files' feature."] Thanks! -- forbin