Slow Adding Files/Folders

[tpatton]

I'm using Vault 3.1.5 and when I use the option "Add Files/Folders" it takes about 20-30 seconds to pop up a dialog box. My directories aren't that large and this happens in every repositiry, even ones that don't have that many files or directories. The machine I am using is a P4 3Ghz w/ 2GB Ram, so it definitely isn't a machine speed issue. I had the same problem in 3.0.

[lbauer]

Is this specific to this client on this particular machine? Does it happen to any other users/machines?

[tpatton]

I'm really the only user and only using one machine so I am unsure. I do know it wasn't always like this but I don't know what changed.

[lbauer]

I'm wondering if the client is having a problem accessing your local drive because of disk fragmentation, anti-virus software, or something else.

You could also try turning on client-side logging to see if there's anything that might point to the problem:
http://support.sourcegear.com/viewtopic.php?t=1534

[tpatton]

Ok, here's a log I just made on a small repository, it took about 10-15 seconds to open the "Add file/Folder" dialog.

[Perry]

(I had to fight through about three occurrences of "You must select a topic to reply to" before this would post correctly -- here is the url "http://support.sourcegear.com/posting.p ... ply&t=5269", which is the same one I see now that it is finally working)

Ever since we started using SourceGear Vault, the Add Files has been slow, as the poster reports here -- I quickly got used to it. I push the Add Files button, and then go do something else, instead of sitting & staring at the client, because it doesn't even put up an hourglass to indicate that it's even trying, but I know it will eventually try & put up the dialog.

[lbauer]

Add files can be slow if the working folder you are invoking it from contains a large number of files and subfolders. The disk speed is
important here. To see if this is the problem, invoke the Add Files/Folders command with no working folders set at all (in a new repository). This should be really fast.

If it isn't, perhaps the slowdown could be the client trying to read devices (like CD drive or network drive), which can be slow on some systems.

Maybe the operation timing out on a network drive. Add Files doesn't try to read network drives, but it does list all the devices that are returned by a .Net call that asks for them, so it might be something in that call.

[tpatton]

Add files can be slow if the working folder you are invoking it from contains a large number of files and subfolders. The disk speed is
important here. To see if this is the problem, invoke the Add Files/Folders command with no working folders set at all (in a new repository). This should be really fast.

If it isn't, perhaps the slowdown could be the client trying to read devices (like CD drive or network drive), which can be slow on some systems.

Maybe the operation timing out on a network drive. Add Files doesn't try to read network drives, but it does list all the devices that are returned by a .Net call that asks for them, so it might be something in that call.

It seems like a mapped network drive on a machine that is currently down was slowing the whole thing down. I did notice explorer didn't have the same slowdown.