why refresh so slow(or why refresh?)

[shen]

one of my daily work is copy files from remote server to local. sometimes I need to select files and choose Copy to left or right. in 2.0 or version before 3.0 b456 it will start copy immediately. but for 3.0 b456 it will refresh for very very very very very very very very very very very very looooooooooong time before start copy, that's really a big setback.
if copy from local server it will be fast, but why so slow for remote servers?

[Michael Bulgrien]

In your default Comparison settings for folder compare sessions, do you have the "Compare contents" option checked? If so, every file pair will be compared during the refresh scan. Try limiting your compare options to "Quick tests" settings when you will be doing work that requires a refresh.

[Aaron]

Which refresh are you talking about? Are you saying you are selecting files, then using Copy To Other Side, and the Copy To Other Side Preview window takes a long time to populate with information? Or that after clicking start it takes a long time to Copy?

Would you be able to send a screen shot of the Copy To Other Side preview screen if that is the issue? If you can, please include the whole BC window (filters, etc). You can also send you BC Settings.zip (Help menu -> Support; Export) to [email protected]
If the Copy takes a long time, how long does it take if you perform the same copy from My Computer / Explorer?

[shen]

steps

we have folder A on local server and folder B on remote server, both folder contains same files and folders(file contains are different but names are same)
I start a session to compare A and B, A at left B at right
-- optional step: wait till all subfolders size information been shown
then I select some files and folders under folder B, right click, choose Copy to Left
then it will show a progress bar above the log panel, show "Refresh..."
that will last very long time(it's so long that I don't have time to wait for it.), no copy started before the refresh finish.
if use 2.0 the copy will start immediately, even though the copy will on top the BC window.

according to what I see from Vista copy, copy from the remote server to local is about 50kB/s to 100KB/s. the files I want to copy are about 10 -100MB.

is about information enough? if not I will record video for you when back to office next Monday.

[Kelly]

This sounds similar to a problem that I have been having with the latest build (456) as well.

I am regularly doing folder diff's between my local drive and a UNC shared folder or to a virtual network drive (ClearCase view).

I have been noticing a lot of extremely long delays in performing operations. It mostly seems to occur when I have let BC3 idle for at least a few minutes. When I come back to it, it can take 20 seconds to even respond to clicking on a different file than was selected to change the focus. Sometimes it ignores the first thing that I attempt to do. If I click again the window title show (not responding). Typically, once it has come back I don't experience delays until it sits idle again.

I have tried the same thing with BC2 comparing the same folders and don't experience this. I hadn't noticed anything like this with BC3 until probably just the last build. I had a lull and didn't use the previous build quite as much, so it may have been present and I just didn't encounter it.

[Zoë]

Kelly,

Your issue sounds like it's hanging trying to detect the free space on the drive so it can display it in the status bar. That's really the only thing that hits the disk when you're just clicking around in a directory comparison. BC2 does the exact same thing though, so I don't know why BC3 would should the behavior and not it. I'd guess that the delay occurs because the OS closes some connection while it's idle and has to reestablish it. The behavior that could be causing a problem has existed for quite a while though; it shouldn't have changed any in a recent build.

[Zoë]

Scratch that. Turns out BC2 caches the disk free space values and only updates them after file operations, which would explain why it doesn't show the same behavior.

[Kelly]

I just confirmed that BC2 does not exhibit the same behavior. I had the same folder comparison open in BC2 and BC3. Allowed them to sit idle for several minutes. Switched to BC2 and double clicked a file to compare. It came right up. I then immediately switched to BC3, double clicked the same file and BC3 sat there non-responsive for 20+ seconds.

I find it hard to believe that something has changed in my system in the last week or two that would have suddenly caused connections to be closed in all cases. Also based on my test, the connection was re-established because BC2 opened the remote file to compare it. Thus when I switched to BC3, the connection was already refreshed. If anything was dropped, it looks like the handle in BC3 was dropped and had to be reopened.

My usage pattern of BC3 hasn't changed since the earlier beta drops, thus it seems that something has changed in the last release or two that has caused this to start happening.

[Kelly]

I have tried turning off all the quick tests and background refresh and set the automatic refresh to 30 minutes. I still find that if it sets idle for even as little as a minute, that it hangs when I attempt to do anything in the folder window and whatever I attempted to do get ignored.

Any suggestions on other work arounds to try?
Is this being investigated?

If this can't be fixed, I may have to switch back to using BC 2. I spend most of my time waiting for BC 3 to finish whatever it is working on, so that I can do my diff's and merges.

Thanks,
Kelly

[Zoë]

I went through our revision control history and I wasn't able to find anything that would have introduced this behavior. If you remember which build you were using before you started seeing the problem email support and we'll send you a copy so you can check whether it was a change in the beta or not. Recent versions were 453 (4/22), 455 (5/6), and 456 (5/19).

[norrisg]

Now I've started using BC3 instead of BC2 for some of the things I do regularly, I'm seeing this slow refresh, but not under the same circumstances. I see it when I tell BC3 to delete files on the remote PC. It sits there refreshing for a noticable period of time before it actually starts deleting anything. BC2 definitely does not have this delay.

[dempson]

A potential explanation for these delays:

Is anyone who is experiencing these delays also using the Code Co-op version control software (Windows only)? Code Co-op 5.1 beta was released in late May, and if you installed it, it causes huge slowdowns in any operation where Beyond Compare interacts with the version control system (via scc.dll), due to a lot of additional consistency checks that are done in beta releases of Code Co-op.

Solution: reinstall Code Co-op 5.0h after you've tested with the Code Co-op 5.1 beta, and wait for the Code Co-op 5.1 final release.

I observed delays of several seconds while doing anything in BC2 which interacted with a Code Co-op project. The most noticeable was comparing two directories in a Code Co-op project which contained hundreds of files. This took about a minute instead of a few seconds, due to Beyond Compare doing some kind of file status check (which it seems to be doing in batches of roughly 100 files at a time for BC2).

If I compare two directories outside of Code Co-op projects, or switch Code Co-op out of the "Check-in Area" view, performance is normal.

If BC3 is accessing the version control system without batching requests (perhaps only in debug builds?), this would cause massive delays with Code Co-op 5.1 beta.

Similiar interaction issues with other version control systems might explain massive delays.

[Kelly]

I don't use code co-op but I do use ClearCase. But in my situation ClearCase hasn't been updated in quite a while and this problem of delays just showed up recently. But I could see that a recent change/bug fix in BC3 could cause this to start happening.

[dempson]

I think I can discount the version control theory. I did a comparitive test between BC2 and the debug version of BC3 beta on a pair of directories controlled by Code Co-op (5.1 beta). There was no significant difference between the two, which means that BC3 (debug) is doing the same degree of batching of version control requests as BC2.

[shen]

seems this issue still in build 467 optimized.
I attached a gif to show what I see here.
the right folder is on a remote server, if copy use ftp or other tools it will be about 20k/s - 60k/s
you can see it refreshing for very long time before start copy.
if there is 1 or 2 files under that folder, the copy will start after less than 5 seconds refresh. but the folder I am copying contains 51 files, that took more than half minutes refreshing.