MyDefrag "battling" W7 system optimizations

[BloodySword]

I MY case it would not. I have 3GB of RAM and it will be filled and cleared very often in big amounts because I use GIMP with VERY BIG Pictures and lots of Layers. Some of the Layers are temporal and will be removed. After clearing the Journal, a LOT of RAM will be freed and Superfetch will refill it. Over and over again.

[Darlis]

After clearing the Journal, a LOT of RAM will be freed and Superfetch will refill it. Over and over again.

Yeah, MS took the saying "Empty RAM is wasted RAM" too serious. 
But I have to totally agree with quanthero. 7's SuperFetch does not have this extreme behavior. In my case, only 1.2 of 4GB are constantly used.

[BloodySword]

Sometimes I have a changing of 1,5 GB in RAM, so it will fire the Superfetch everytime I have this...

[Kasuha]

If nothing else, as far as I know reading wears the disk out far less than writing. Superfetch does not write on the disk.

I have just ran the optimization of my disk with updated script and I was surprised how much of the data was still in place after such a long time and how fast the run was. I only skipped last zone as it contained many big and fragmented files and I decided to not defragment them this time. If you're interested, the script I used was this:

Code:

Title('Fast Optimize C:')
Description('Fast Optimize disk C:')

Debug(0)
#Debug(431)

VolumeSelect
  Name ('C:')
VolumeActions

  FileSelect
    ImportListFromBootOptimize()
    and SelectNtfsSystemFiles(no)
    and Directory(no)
    and Size(0, 50 Mi)
  FileActions
    Defragment(Fast)
    FastFill()
    AddGap(Minimum(RoundUp(ZoneEnd + VolumeFree / 100, VolumeFree / 100), RoundUp(ZoneEnd + 2 Gi, 1 Gi)))
  FileEnd

  FileSelect
    not(
      SelectNtfsSystemFiles(yes)
      or Directory(yes)
      or Size(50000000,0)
      or (LastAccessEnabled(yes) and LastAccess(,1 month ago))
      or DirectoryName("$RECYCLE.BIN")
      or DirectoryName("RECYCLED")
      or DirectoryName("RECYCLER")
      or DirectoryName("$*")
      or DirectoryName("Downloaded Installations")
      or DirectoryName("Ehome")
      or DirectoryName("Fonts")
      or DirectoryName("Help")
      or DirectoryName("I386")
      or DirectoryName("IME")
      or DirectoryName("Installer")
      or DirectoryName("ServicePackFiles")
      or DirectoryName("SoftwareDistribution")
      or DirectoryName("Speech")
      or DirectoryName("Symbols")
      or DirectoryName("ie?updates")
      or DirectoryName("dllcache")
      or DirectoryName("Installshield Installation Information")
      or DirectoryName("System Volume Information")
      or DirectoryName("windows.old")
      or FileName("*.7z")
      or FileName("*.arj")
      or FileName("*.avi")
      or FileName("*.bak")
      or FileName("*.bup")
      or FileName("*.bz2")
      or FileName("*.cab")
      or FileName("*.chm")
      or FileName("*.dvr-ms")
      or FileName("*.gz")
      or FileName("*.ifo")
      or FileName("*.iso")
      or FileName("*.log")
      or FileName("*.lzh")
      or FileName("*.mp3")
      or FileName("*.msi")
      or FileName("*.old")
      or FileName("*.pdf")
      or FileName("*.rar")
      or FileName("*.rpm")
      or FileName("*.tar")
      or FileName("*.wav")
      or FileName("*.wmv")
      or FileName("*.vob")
      or FileName("*.z")
      or FileName("*.zip")
      )
  FileActions
    Defragment(Fast)
    FastFill()
    AddGap(Minimum(RoundUp(ZoneEnd + VolumeFree / 100, VolumeFree / 100), RoundUp(ZoneEnd + 500 Mi, 500 Mi)))
  FileEnd

  FileSelect
    SelectNtfsSystemFiles(yes)
  FileActions
    PlaceNtfsSystemFiles(Ascending,MftSize * 0.1)
  FileEnd

  FileSelect
    Directory(yes)
  FileActions
    Defragment()
    FastFill()
    AddGap(Minimum(RoundUp(ZoneEnd + VolumeFree / 100, VolumeFree / 100), RoundUp(ZoneEnd + 500 Mi, 500 Mi)))
  FileEnd

  FileSelect
    all
  FileActions
    Defragment(Fast)
    FastFill()
  FileEnd

VolumeEnd

[BloodySword]

That's a cliche. Reading takes more movements than writing. Writing is conigonous most of the time, where reading is random most of the time.

[Kasuha]

And why is number of head moves important? They don't touch the plates...

[quanthero]

Prolonged head movements generate a lot of heat, and heat is not good for hard drives (and most electronics in general).

[Kasuha]

I don't see any problem with disk temperature on my system. If that's the only thing with superfetch I think I can leave it on.

[jeroen]

as far as I know reading wears the disk out far less than writing.

There is no difference as far as wear and tear is concerned between reading and writing.

And why is number of head moves important? They don't touch the plates...

All mechanical movement results in wear and tear. Harddisk heads never touch the plates (well, maybe when the harddisk is off, I'm not sure about that).

The function of SuperFetch is to prefetch data from harddisk when you start a program, so data is already in memory when the program needs it. There is no extra disk movement, the data will be needed anyway. Actually there is less disk movement, because disk access is optimized by the disk cache, made sequential. Sometimes there is also some unnecessary work, in cases where it makes a wrong prediction and reads unneeded data. I think the total of these effects is that SuperFetch is disk neutral, the total disk usage is about the same, with or without SuperFetch. It is just that disk access is at a different point in time, and perhaps this confuses people into thinking it is doing extra work.

There is still the huge memory consumption by SuperFetch, though. Another point is that MyDefrag has already optimized the files on disk, so the benefit of SuperFetch is reduced, if not nullified.

[BloodySword]

There is still the huge memory consumption by SuperFetch, though. Another point is that MyDefrag has already optimized the files on disk, so the benefit of SuperFetch is reduced, if not nullified.

That's the reason I don't use it. My question is, why did you praise SuperFetch in the thread of my tutorial and now you have pointed out that it is useless together with MyDefrag?

[jeroen]

why did you praise SuperFetch in the thread of my tutorial and now you have pointed out that it is useless together with MyDefrag?

Well, in that other thread you argued that MyDefrag optimization will reduce the benefits of SuperFetch. I have thought about it and I think you are right. Please note that I am not saying that SuperFetch is "useless". I still think SuperFetch makes program starting faster, the effects will not be nullified in all cases.

[Vanex]

I see no reason to stop using it unless MyDefrag comes with something significantly better, such as option to defragment large files in place.

How comes that MyDefrag is not defragmenting in-place?
Since I see MyDefrag moving clusters and not entire files, it shall be able to fully defragment any partition even with one single cluster being free.

[BloodySword]

No that is not possible. For security reasons a cluster has to be copied. If the copy is consistent, the old clusters are removed from the MFT.

[jeroen]

How comes that MyDefrag is not defragmenting in-place?

A fragmented file is a file that is split into pieces, and the pieces are placed at various places on the disk. Defragmenting a file is moving all those pieces back together into a single big block. It is totally impossible to defragment a file by leaving it in the same place, it would remain fragmented.

What Kasuha means by "defragment in place" is to leave the first fragment of a file where it is, vacate the disk space after that first fragment, and move the rest of the fragments there, joining them up. It is a timesaver because the first fragment does not have to be moved.

MyDefrag can defragment very full harddisks, even if there is only a single free cluster. It just does it a bit differently, that's all.

[Kasuha]

What Kasuha means by "defragment in place" is to leave the first fragment of a file where it is, vacate the disk space after that first fragment, and move the rest of the fragments there, joining them up. It is a timesaver because the first fragment does not have to be moved.

While this description is generally correct I'd like to add some details.
By defragmenting a file in place I mean checking if leaving some (likely large but not necessarily first) fragment in place and moving the rest around it does not accomplish the task in fewer data moves than moving the whole file to a new location.
Of course if it would mean more file moves (e.g. because of need to vacate too much space around the fragment), then the right option is to move the whole file to an empty space.