locked
SyncToy 2.0 (not beta) is painfully slow RRS feed

  • Question

  • I did see a similar post to this about the beta but went ahead and upgraded my trusted v1.x which I have been using for years.

    However I find that the new v2.0 is indeed painfully slow compared to the old one. I'd say more than two or three times as slow.

    I am contemplating reverting back to the old version - any ideas?

    thanks

    Paul Woody.

     

    Wednesday, August 27, 2008 5:38 PM

Answers

  • Hi -

    Please upgrade to SyncToy 2.1 to see if if fixes your issue.

    Thanks
    Deepa
    Deepa ( Microsoft Sync Framework)
    Tuesday, February 16, 2010 8:39 PM
    Moderator

All replies

  • Hi Paul -

     

    Can you give us more information about your folder pair? Also, was this slow on the first sync AND every subsequent sync after that?

     

    Thanks

    Deepa

    Wednesday, August 27, 2008 5:44 PM
    Moderator
  • Paul, is this on first sync after upgrade?

     

    Wednesday, August 27, 2008 5:45 PM
    Answerer
  • i have a number of them - all my important data:

    - bwprojects 2.52GB (synchronize - mostly zip files but a few extended TIBCO BW project repos)

    - Data 42.8GB (synchronize - my complete c:/Data with SyncToyData subfolder not included)

    - Desktop 5.5MB (echo)

    - eclipseprojects 21.5MB (synchronise)

    - Favourites 313KB (synchronise)

    - OutlookData 2.51GB (Echo - there are some big pst files here)

     

    Usually I only run Data - for a quick sync of my current work - this used to be reasonably quick - but even this runs like a dog now.

     

    I have been using SyncToy 1.4 for over a year now and the speed has been ok.

     

    When I first ran SyncToy 2.0 on the same folders it took literally hours and hours maybe 4 or 5 hours.

     

    Now when I run it on Data even with no changes it takes about twice as long "looking for changes" - it used to take just a few minutes.

     

    If I run it on the whole set - with no changes - it also takes maybe twice as long

     

    I think I will may decide to revert back to 1.4 - are there any caveats to doing this?

     

    Thanks

    Paul.

    Thursday, August 28, 2008 11:08 AM
  • Paul, when you say it takes "twice as long", do you mean the no-changes sync take 10hours or twice as long as 1.4? The times should get better on the larger folder pairs as you run it more times because it will give SyncToy a chance to catch up on re building the metadata indexes.

     

    Tuesday, September 2, 2008 4:26 AM
    Answerer
  • The initial run after "upgrade" took about 10 hours.

    Now it has settled down a "no changes" sync takes at least twice as long as it did before.

    It seems to spend all of its time "searching for changes".

    Very annoying.

    Paul.

     

    Tuesday, September 9, 2008 6:27 PM
  • Sorry - I know it can be annoying when things are slow. Can you give us more information on how your folder pairs are set up ( what are the options picked). Are you synchronizing two local hard disks or a remote location? What is the size of the data you are synchronizing and how much time does it actually take?

     

    Thanks
    Deepa

    Tuesday, September 9, 2008 11:54 PM
    Moderator
  •  

    I have 6 folder pairs-

     

    Echo Desktop 5.60MB 59 Files, 5 folders
    Sync Favorites 315 KB 1,223 Files, 118 Folders
    Sync Data 41.5GB 59,216 Files, 10,188 Folders
    Echo OutlookData 2.58GB 10 Files, 1 Folders
    Sync BWPROJECTS 2.55GB 33,149 Files, 14,730 Folders
    Sync ECLIPSEPROJECTS 21.5MB 360 Files, 193 Folders

     

    The folder pair I sync most often is "Data" - it is the biggest and it now takes much much longer to look for any changes - even when there are just one or two files that changed (which is often the case).

     

    Both are local disks - one is my internal HDD the other is my USB HDD.

     

     

     

    Pretty common setup I would imagine.

     

    Paul.

    Saturday, September 20, 2008 11:38 AM
  • Hi,

     

    I had left Synctoy alone in September because of the speed. Just installed again last weekend and it still seems incredibly slow. Was there ever an improvement on the product or a suggestion elsewhere on how to get to better speed

     

    thnx

     

    Wednesday, January 21, 2009 10:43 PM
  • Hi -

    The initial sync will be slow - have you tried syncing another time?

    Thanks
    Deepa
    Thursday, January 22, 2009 9:33 PM
    Moderator
  • For me the first sync takes a substantial amount of time. Successive syncs are faster.

    To prevent frustations, my application loads with a  splash screen; with parallel threads working concurrently.

     

    Friday, January 23, 2009 11:55 AM
  • I just tried to use the 64 bit version on my Vista machine.  Had over 9000 replaces (15GB).  Stopped it after 16 hours and only 3500 operations completed. 

    Also noticed that the CPU percentage goes to 100% when synctoy is running.  This version seems to be a failed product. 

    Wednesday, April 29, 2009 8:39 PM
  • Hi -

    The initial sync will be slow - have you tried syncing another time?

    Thanks
    Deepa
    Hello Deepa,

    I have the same issue, I have been using SyncToy 2.0 for about 4 months now, every week, for backup purpouses.

    The initial sync was indeed slower than the following. But I am getting really tired of waiting SyncToy 2.0 each time it "gets lost" while copying and while renaming , mostly over XLS files, but on other filetypes too (.txt, .xml and .swf, for example).

    I am about to revert right now to my SyncToy 1.2, since that is the last Setup file I have kept.

    If a 2.1 version should appear, I would give it a try, but right now, it is a good bye for 2.0.

    Please get me right on this: I am greatful for a good product form your team. I have been using version 1.2 for years, along with other PowerToys.

    I just wonder how is it possible that there are no upgrades on SyncToy 2.0, given this very important issue.

    FYI:
    - I use Windows XP Professional SP3
    - I do my Sync between two local hard drives.
    - I have 8 Sync pairs, all set to Contribute
    - There are a total of 33588 files using 5.16 GB that get sync'd
    - Since I run this every week, an average of 300 files get updated each time.

    Thank you very much, again.

    Saludos,
    Alejandro Quiroga.


    • Edited by Alex QA Thursday, April 30, 2009 11:57 PM
    Thursday, April 30, 2009 11:23 PM
  • I'm going to skip my system technicals (outside of Vista 32 current sp, 4 sets of synch executed as a run all) and try to describe the behavior more specifically. 

    I renamed a number of photo folders on the c drive that are backed up to an external hard drive.  I noticed instead of synching the folder rename to the external, it appeared to instead do the copying/renaming/copying/renaming that Alejandro describes above.  So I ignore it, assuming it'll take the inefficient way once for whatever reasons of its own, and hopefully it won't happen again. 

    Then I notice it appears to be repeating the same actions when I try backing up the next time, as if it didn't realize it had already done that (although maybe it included some other old photo files that had not been updated, unless it was on account of a picasa file (.ini or something?), but it shouldn't have had reason to update). 

    I think it's taking longer because 1, it's doing folder name updates the long way, and/or more importantly, apparently executing redundant actions. 

    Moore's curve appears to have plateaued on the processor speed side and Vista's frustratingly sluggish without any help ;-) but I'm definitely a fan of Synchtoy.   Maybe this might help focus the diagnosis if somebody hasn't figured it out already. 

    Thanks. 


    Saturday, July 4, 2009 4:08 AM
  • This thread needs a bump, somebody's not paying it the attention it really deserves. 

    Out on the FAQ they have a misguided suggestion that if you have a full recycle bin, it might slow things down. 

    That is an EFFECT, not a cause.  The reason the bin's so full is because SynToy is deleting and restoring things needlessly -- in the same location they were. 

    If they're interested in the problem, it's not hard to recreate.  Just run an operation and watch the status bar below.  It will toggle between a bunch of delete and copy operations.  The deletes frequently don't belong there.  I don't know if it's recreating everything it's ever done repeatedly and cumulatively, but I have constructive suggestions above, and I'm pretty sure a lot of music folders from my backup drive that are now in the recycle bin were never even renamed. 

    Like I said, I love SyncToy, at least in theory or how it used to work, but Vista clogs down to slow enough as it is without any help (even with a registry cleaner and defrags etc etc).  I'm not even using ST any more, I'm back to manually copying folders.  You can't fix a problem that hasn't been correctly identified, but this one doesn't seem that hard to pin down to me, if some engineer gets the time to read the thread. 
    Tuesday, July 21, 2009 8:12 AM
  • If they're interested in the problem, it's not hard to recreate.  Just run an operation and watch the status bar below.
    Well - I just first started to experience these speed problems now. I have been using SyncToy 2 for some time now on different machines (all 'Echo') doing backups of my 40.000+ photo collection. Until last night (where I did a new SyncToy installation), the initial scan took not much longer than than running it a second time.

    So its not all just black and white. :-)

    With that said, I am having the slowdown problem now - I am still waiting for the initial scan to complete. Glad to see that it remembers the progress it has made.

    But it does look like it is fast in the begining and then getting slower and slower. It is not huge folders that takes time. Right now it has been about 2 minutes to scan though a folder with 27 files. Can the path length be a problem? I seems often to be folders with a long path.

    My Setup:

    Windows 7 RC 64 bit: Core i7, 6 GB RAM.
    8 Echo operations from Synology NAS to local 1,5 TB Maxtor USB disk. The Maxtor disk is encrypted with TrueCrypt.
    No load on computer, NAS or network
    Total: Around 230 GB data in 76.000 files.

    This is my first time, running a job of this size.
    Wednesday, July 22, 2009 7:57 AM
  • Okay, I let it run for 4-5 hours to finish off, here's my latest observations. 

    -  It does not appear to be duplicating file copies (tested preview after completion), actions are unique and get closed. 
    -  It's still "renaming" by copying and renaming location; if it's a security thing, still could be part (?) of speed problem
    -  It DOES seem to be taking longer than expected to execute the simple write operations.  the 5-700k jpg's it used to copy in I think a second or less were now taking 11 seconds each.  Like I said, just about everything else about vista now, even with fast hardware and standard security precautions, is nightmarishly slow, in some contexts even just typing a character takes five seconds before it even visually responds with another 5-15 seconds of hourglassing to execute onscreen, but I can't tell for sure if that's related or not, you'd think it would process fine once it got underway. 

    Could Deepa or somebody indicate whether this subject is still of interest/concern? 
    Wednesday, July 29, 2009 7:18 AM
  • Could Deepa or somebody indicate whether this subject is still of interest/concern? 
    Thank you JustAnotherSurfer for your contribution to this thread. The third issue you mention on single file operations that take MUCH LONGER than they are expected to, DOES happen also on my Windows XP SP2 and SP3 Systems. So I guess that even though Vista might have some issues to be blamed on, this one is not its fault.

    I am back to my SyncToy 1.2  since three months ago now, and it's pretty fast.

    Just like you, I really would like to know if this issue is still of interest/concern.
    Wednesday, July 29, 2009 12:18 PM
  • If it's going to be a while till a moderator shows up, I want to try a random guess/theory.  I use Picasa for a photo organizer, and it uses picasa.ini files in the directories it tracks pictures in.  I don't know if that affects album art in music collections or not, but it would definitely affect photos, and I wonder if it's possible SyncToy is seeing those files updated and assuming it has to update all the files in whatever folder.  You wouldn't expect this, but on the other hand we seem to be getting unexpected behavior as it is - I watched ST do copy operations on files I know I didn't modify since the last sync.  Anyone else with this problem a Picasa user? 

    I guess I'll have to see if I can find a download for version 1.2 instead of the point uh-oh ;-)  At least since it's just file operations there shouldn't be an retrocompatibility issues.

    Short off-topic:  {rant} Computer keeps freezing up for 20/30-second intervals every 5-10 seconds or so, with a message below about its communication with i1.social.microsoft.com, it gets really annoying when you have to type up your message in notepad and paste it back.  Maybe it's well intended as a backup or something, but if we're going to get a microhoo merger, maybe they can borrow the yahoo bulletin boards so it doesn't have to phone home to Redmond every other moment.  Maybe it's a temporary behavior, but it doesn't seem like it, and that would be not just dumb but creepy.  {/rant}
    • Proposed as answer by tims31 Monday, August 10, 2009 10:57 AM
    Sunday, August 2, 2009 11:41 PM

  • Possible solution????

    I have been using Synctoy for syncing my website files between my desk top and laptop with an external HD since 1.4 and had no issues. Having just upgraded my laptop and it using Vista had to install synctoy to this.

    Syncing these files used to take 10mins max but again as most users have stated it was soooo slow...gave up after two hours. My external drive was formated as FAT 32 and the old laptop and desktop NTFS so didn't think this would be the problem but I have now converted my external drive to NTFS and the Sync was performed again in less than 10 mins (including initial pairing setup).

    Not sure if this will work for all but certainly worked for me. During the conversion process the drive was reported as "dirty" and had to be check and repaired. As I say may be a solution for people to check? To check the drive select in explorer right click > tools > error checking. Select auto fix and scan selection boxes.

    Conversion of all drives to NTFS may be a solution.
    Monday, August 10, 2009 11:10 AM
  • One further observation, see if anyone else has had the experience.  (Interesting NTFS idea, though I'm not sure I'm brave enough to try resetting something like file formatting until I see more on that subject.) 

    I had read in the white paper that Synctoy would probably recognize identical copies of a given file.  Since I usually added just a few known files daily, I often copied them manually rather than running ST2 to do the update, because running it as a sync would take somewhat longer.   My assumption was, the sync would see the exact file copied in location A that it had already been copied from in location B. 

    I am now not sure this is the case and wonder if the deleting and rewriting process is an effect of a failure to recognize a file as a copied/pasted copy of the original.  

    Did anyone else make this assumption? 
    Monday, August 24, 2009 4:36 AM
  • Like others here, I am running SyncToy 2.0 for the first time after using 1.4 previously, and 2.0 is performing *painfully* slow.  Syncing here between two laptops, both running XP SP3 with all critical updates, over 100Mbit ethernet.  Drives on both machines are formatted with NTFS, however folder being synced on one machine is using Offline Files, and I am not presently connected to the server (The offline files server is over 300 miles away, so that isn't currently an option!).  The path that I would like to sync contains 4203 files in 1045 folders, for a total of 22.4GB.

    Well actually I haven't even got to the sync part yet, I'm just attempting to run a preview.  The preview process seems to start out reasonably quick, but then appears to get exponentially slower as more files are encountered.  Right now its about 25% done with the preview process according to the progress bar, and might as well be sitting still.  The current directory that it is processing only has about 110 files, and it's been sitting here grinding on that single folder for over 5 minutes.  There are some fairly large files in that folder (total about 1.2GB), but I do *not* have the option selected to check file contents so I wouldn't think the size of those files should matter...?

    Anyone know what's going on?  Is this new version really just that bad, or am I missing something?  As it is, this won't even come close to working for me.  So I am about to head for the web to check out latest versions of LapLink, Allways Sync, and anything else that seems promising.

    Oh, and BTW, since I am just trying to do a preview, my slowness doesn't have anything to do with possible Recycle Bin related issues.
    • Edited by kamyers1 Thursday, September 17, 2009 9:02 PM more typos. :-(
    Thursday, September 17, 2009 8:58 PM
  • I tried v2.0 some year ago, and switched back to v1.4 because it was painfully slow. Now I try it again, and still no improvement.

    These forums are full of MS developers, but the same big issue that people are complaining about is after a whole year still unsolved. v1.4 is good, but I can't use it because it doesn't support paths larger than some 256 (?) characters. So I eventually have to manually look the files up that it can not sync. v2.0 on the other hand, is way too much CPU and time intensive than v1.4, and I don't even get the chance to see whether it supports large paths. It continues to work endlessly on some 50k files. “Check file contents” is unchecked, the 100Mbit network connection keeps a constant utilization of 3% (!!! what for???), CPU at some 75%. It doesn't make sense. Does this make v2.0 even worse than v1.4?

    So what's the problem? I wouldn't bet on incompetence. But then again, what is it? In serious companies like MS, such problems shouldn't even exist, let alone left unfixed for more than a year.

    Kind regards,
    Davor

    Tuesday, September 29, 2009 4:08 PM
  • I tried v2.0 some year ago, and switched back to v1.4 because it was painfully slow. Now I try it again, and still no improvement.

    These forums are full of MS developers, but the same big issue that people are complaining about is after a whole year still unsolved. v1.4 is good, but I can't use it because it doesn't support paths larger than some 256 (?) characters. So I eventually have to manually look the files up that it can not sync. v2.0 on the other hand, is way too much CPU and time intensive than v1.4, and I don't even get the chance to see whether it supports large paths. It continues to work endlessly on some 50k files. “Check file contents” is unchecked, the 100Mbit network connection keeps a constant utilization of 3% (!!! what for???), CPU at some 75%. It doesn't make sense. Does this make v2.0 even worse than v1.4?

    So what's the problem? I wouldn't bet on incompetence. But then again, what is it? In serious companies like MS, such problems shouldn't even exist, let alone left unfixed for more than a year.

    Kind regards,
    Davor

    Tuesday, September 29, 2009 4:09 PM
  • I tried v2.0 some year ago, and switched back to v1.4 because it was painfully slow. Now I try it again, and still no improvement.


    I too was a former 1.4 user and have used 2.0 from time to time on my wife's Windows XP-32 PC. I haven't had much trouble or experenced slowness, but I had already synced most of the data to the location I was echoing before upgrading to synctoy 2.0. So on her PC I never really noticed the slowness issue as it's mostly word docs and family pics that get syned from time to time.

    however, today I installed a new drive to the PC I sync all her data to with plans to sync all my data (about 150GB worth). I set up an Echo folder pair and the inital "discovery" run took a little time but didn't seem odd to me due to the amount of data I have. I then kicked off the actual echo process. I checked my network speeds on my PC and the PC I was syncing to. I run a GB network and usually see about 200-250mbps sustained and occasionally 400-500mbps bursts for very large files. Sync toy was running at roughly 70-80mbps. I didn't think much of it and left.   I came back a few hours later (just now) and
    the sync proces sloked tobe roughly 10% complete and network transfer speeds look to be crawling at roughly ONE mbps...yes as in 1... Uno. Ok I admit it occasionay doubles it speed to a glorious 2mbps burst from time to time...YIPPPEEEE!!!

    I stopped the sync and this time disabled antivirus on both systems in case it was the cause. I restarted the sync... the discovery process ran at an acceptable pace. Then the actual sync began. I checked network speeds and they were back to 70-80mbps transfer. Ok fine as long as this thing synced. Sadly about 10 minutes later we're back to 1mbps.

    Lets add SyncToy 2.0 to the Windows ME (Miserable Edition) club. I suppose "Toy" is in the name for a reason and it's worth what is costs. I was hoping for an easy to use sync solution with pretty GUI and all that fluffy stuff. But I guess I'm just going to fall back to robocopy.exe scripting since this is obviously an abandoned, failed project. Oh well. To Microsoft I say what I'd say to the Atlanta Braves... "Nice try. Maybe next year".
    Sunday, October 4, 2009 7:10 PM
  • It is an interesting message. I use a program to file synchronization, which is called File Sync File sync and backup software (http://www.fileutilityblog.com/archives/229) is a necessary thing for everybody. That is why I use this program and haven't such problems. Tell me, please, the differences between these two programs.
    Sunday, October 18, 2009 2:45 PM
  • This worked for me echoing my folders: Under "change options" select "Exclude system files", and un-check "Save overwritten files in the Recycle Bin".
    Wednesday, October 28, 2009 3:13 PM
  • *** POSSIBLE DIAGNOSIS ***

    It can't possibly be this simple, can it? 

    So I run it again today, and I see Synctoy is - again - needlessly overwriting a huge pile of photos and music albums, stuff I KNOW hasn't been changed or updated, but there it goes again, deleting/rewriting and therefore rapidly clogging up my recycle bin, when my remaining disk space could NOT possibly accommodate pointless wastage like this.  So I cancel the sync and empty the many gigs of duplication dumped in the recycle bin for nothing, knowing I might have to do this several times now. 

    Then I look at where I interrupted the operation in the final tracks of a particular album, and I start thinking, "You know how sometimes you copy files in Explorer and it asks you if you want to overwrite one file with another, and the only difference is one hour's difference in the file date/time?"  And I think, s.t. couldn't POSSIBLY be overwriting my entire music and file collections just because it can't recognize the timestamps are identical except for Windows' screwy unpredictable failure to recognize daylight savings or something, can it? 

    So I look at the unfinished C drive copy and I compare them to the external hard drive versions, and sure enough, there's a one-hour time difference in the file created timestamps.  I don't know how Windows reads its own date/time data, and/or adjusts it in one place and not in another, but there's the reason it was foolishly overwriting my entire music and photo collections, which were current and intact and previously already synced and fine.  This might not exclude other possible causes too, but it sure looks like one very real explanation for why it's happening.  That might also explain why the behavior is seemingly unpredictable, fine at times and frustrating at others. 

    MODERATORS, PLEASE READ THIS AND COMMENT!
    • Proposed as answer by Bellcross Monday, February 15, 2010 9:31 PM
    Sunday, February 14, 2010 11:07 AM
  • While the last post by justanothersurfer may identify a solution to *some* of the performance problems that have been encountered with SyncToy 2.0, it *CANNOT* be the solution to all of them, particularly the case that I reported previously.  In my scenario, SyncToy 2.0 was painfully slow just running a *PREVIEW*, therefore the slowness is occurring long before any actual copying and renaming of files might occur.  So the slowness in that case cannot be explained by the one hour file difference issue causing files to be copied/renamed than shouldn't need to be.  Perhaps it could be something vaguely related, such as an internal cash of required file actions growing too large to fit in available RAM...

    By the way, since encountering this problem with no reasonable solution ever proposed or offered by anyone with Microsoft, I have switched to using AllwaySync, and generally been very pleased.  I did have to pay for the license, but the cost is quite low.  AllwaySync's only serious shortcoming for my purposes is that it doesn't provide any way to sync files that are currently in use.

    Tuesday, February 16, 2010 2:36 AM
  • Yeah, I mentioned in paragraph three it doesn't exclude other causes also, but this is fascinating as one real cause of problems in its own right, and if as it positively appears ST's subject to the same confusion Explorer suffers on the timestamp, it will choke your drive if you let it do its weird thing, since for most people it'll exhaust all available drive space. (By the way, not sure which thread, though probably a speed-related one, but I remember noticing one of the moderators discussing preview as not a flawless predictor of behavior. If you poked around it might be of possible interest too, but I defer to them and decline to weigh in on that one.) Can't wait to see a mod reply, sure looks like this one's worth addressing.
    Tuesday, February 16, 2010 7:46 AM
  • Hi -

    Please upgrade to SyncToy 2.1 to see if if fixes your issue.

    Thanks
    Deepa
    Deepa ( Microsoft Sync Framework)
    Tuesday, February 16, 2010 8:39 PM
    Moderator