Darlis is right. MyDefrag does not read from the disk by itself, and therefore does not have any buffer. Zero. Nothing. The actual moving of data is done somewhere deep inside Windows. I have no idea what buffer size Windows is using.

Thanks Darlis and jeroen!  "Buffer" might have been the best word to describe what I was trying to get at.  It sounds like you two addressed it exactly.  It is too bad MyDefrag doesn't use a buffer as I still can't help but think defrag operations would go so much faster with one.  All up to Windows' defrag API though it sounds like.

Then again, there are probably good reasons not to try to implement a buffer in MyDefrag - or perhaps there just hasn't been time to implement it yet?  I know with some disc-burning applications you can set a buffer size (beyond the typical 2 MB hardware buffer), though I wonder if the application in that case operates on a "lower" level (closer to hardware) than MyDefrag does and that's why it can do this.

Does anyone know if a read/write buffer is being considered as a future feature?  I really wonder if the potential for speed improvement is as great as I'm thinking.  From what little I know, it seems like it could even be revolutionary if no one else does it currently - opening up whole new possibilities for algorithms etc.

Thanks again - glad you two understood me haha.

I'm trying to find out how much data gets moved at once when files are rearranged on the HDD, and why it appears as though only small amounts are transferred at once.

For instance, I see in the status bar a file about 2.5GB is being moved and I see in Windows 7 x64 Resource Monitor that data is being read at ~6 MBps and written at ~6 MBps, for total disk activity of 12 MBps.  I wonder what size the little bits of data are that are being read then written to move this large file.  MyDefrag 4.3.1 is using about 60 MB of "private working memory" in task manager, so I know it is not transferring the whole file at once.  Further, all HDDs I'm familiar with physically can't read AND write at the exact same time - that would require multiple independent read/write heads or some other thing I'm positive my laptop doesn't have.

I do have 10GB of ram, however, and I know my HDD can read/write much faster than 6 MBps if it's not thrashing back and forth trying to read and write these little bits.  If the file was read all at once in its entirety (2.5GB to ram) then written all at once to wherever MyDefrag wanted the little bits moved I can't help but think it would go SO much faster.  I know 10GB is more than typical but I do assume a lot of people have significantly more ram available than what MyDefrag uses so this wouldn't just apply to my case.

This wouldn't put the data in any more danger than usual because the original data could be not marked for deletion until it is entirely relocated - just like in a regular "move" file operation.  Even if it was transferred in less crazy chunks like 100 MB at a time, to reduce power failure risk (or for whatever reason such small transfers are currently used), I would still think dramatic speed increases would be possible.  There could be a setting for how much ram MyDefrag is allowed to use (with a 100 MB default or whatever).

So what size does MyDefrag use currently, and what am I missing?  Why doesn't MyDefrag transfer files in as large of "batches" as a user's ram will allow?  If there already IS a setting that pertains to this, where is it and how do I use it?

Thank you!!!!

(Sorry in advance if this has been discussed at length many times before.  I tried looking but have no idea what terms to search for or what the right technical name for these "pieces" really is.)