D
dimmy32
Guest
I tried out the Microsoft one, that came with XP-and it's really, really slow. Is there a reliable defragger for win XP yet ?
Originally posted by Mike89
I have been using Vopt for awhile now in both 98 and ME. The best dam defragger I have ever used. It's currently not compatible with XP but they will have it out shortly. This defragger isn't well know but I'll put it up against anyones. It can be purchased at www.goldenbow.com
(And, all of the most recent versions of defraggers have adopted this, even Executive Software's Diskeeper 7.0 which is radical because they stated it would not make a diff. only theoretically... well, they have seen the light & had to alter their code for that as well, there is no denying that XP's own native BootOptimization/OptimalLayout features work... speeding up the boottime at the VERY least!)
.S.=> Speed4Ever's mentioned something I have slowly been working on that improves Speedisk working WITH XP's native BootOptimization/OptimalLayout feature... & it is working! I can run them BOTH concurrently/simultaneously without them getting into "Tug-of-War" conflicts on files XP is working on! Simple program, tells Speedisk to ignore the files XP works on for BootOptimization/OptimalLayout & is working out well, only waiting for some feedback from Symantec on it really at this point... & some minor issues about MFT$ placement, which personally, from writing to Speed4Ever, I think Norton has a BETTER idea to place it to the outermost faster disk tracks... why? Well, MS puts it into the middle of the disk... which is FINE because BTree seeks start there... so you will find the file fast! BUT, on the outer tracks it will read it faster... what's more important? Finding it fast (which B-Tree seeks would find it in two seeks rather than one on outer tracks) OR, reading its contents in & out faster as Speedisk yields? I will take speedisk's philosophy on that... apk
As a matter of fact, from you! You're the one that told me Diskeeper 7.0 changed their work to do bands of files placements in email to me, right?
Originally posted by AlecStaar
Glad you see those points above, about logicals & filesystems addressing only NOT being a good way to look at this stuff only...
See, unlike software in RAM that is FULLY addresseable thru ALL POINTS IN RAM equally fast using X86 or better CPU's, technically at the same speed... pure logical, disks are NOT that way. They deal in the physical, & pure theory alone, BREAKS DOWN when dealing with that.
Like you said: Real world results! Mine are not like yours, we both tested that before, my second FULL DISK DEFRAGS take me roughly 10 minutes!
On disks, you have the physical to address: Disk head swings! Just like NTFS was said by MS initially to be "frag proof/frag resistant" & that proved to be TOTALLY untrue. NOT PHYSICALLY POSSIBLE, especially when files are created/destroyed alot on a disk.
Faster read/writes (the goal of ANY file, not just its seektime) is where Norton's placement of MFT$ & Pagefiles on outer tracks, WHALES on Ms' philosophy of middle of disk placement: YOU GET FASTER READ/WRITES ON THOSE FILES!
(That is their goal, both MFT$ & Pagefile: faster reading/writing of their contents... faster with Norton's placements!)
I myself, and you know this, we tested it... get EXTREMELY FAST DEFRAGS WITH NORTON! You know that, we tested it at NTCompatible.com, I had to see if mine was like yours, & it's not after a good first run I did days before!
BUT, the first run was VERY slow for me... it had finally had enough access counts to files & particular ones I use, to pull of a "Bands of most used vs. least used" placements. Even Microsoft had to concede this, & built in their Bootoptimization/OptimalLayouts into their OS... tossing out MoveAPI file constraints EVEN IN THE DEFRAGGER! That also limits its defragging ability to 4096 sized sectors/clusters.
Norton... knows NO SUCH LIMITATION & can move files like Pagefile/directories/MFT$ during runtime... even Diskeeper has adopted this, & why? SUPERIOR UPTIME! No need for reboots!
* Imitation IS the sincerest form of flattery... seems both MS & Executive Software (both companies I admire alot) had to imitate Symantec/Norton this round... no denying this!
🙂
APK
P.S.=> On our patching it? Listen... be patient! I don't like operating without ALL the facts... I think we need to waitout Symantec's reply is all... I rarely fail on a programming task, this will NOT be one of them, but many times I too, had to be patient. Wait out answers... recently, I had to with my APK Registry Cleaner 7.0++ with Lonman, & I overcame that too. This will be NO different.
Right now? I think we have a good 90% of it done... no doubt in my mind! BUT, the MFT$ & PageFile.sys placements... man, from what I told you above, can you say it is inferior to that of MS? apk
Originally posted by AlecStaar
Ugh, see above! lol..
APK
Now on ignoring those files? I have an email from you here in front of me now, that says you saw the UNMOVEABLE black patch grow bigger in Speedisk after we populated it & you ran Speedisk... you have seen that, or so you told me in email!