gets take long time, high continuous cpu usage on client pc

[GrandPixel]

SourceSafe 6.0 / SourceOffSite 4.2

When I do a get from source control from wtihin Visual Studio, the SourceSafe/SourceOffSite server's cpu usage (older 2.8GHz dual-core Xeon) is less than 5% with a few brief increases, and the memory usage for SosService.exe stays at about 90MB. But the development machine's cpu usage (core 2 duo 2.53GHz) is sparatic but averages roughly 50%+ with memory usage at 400MB or so for devenv.exe. A full get of one of the solutions takes at least an hour, and the resultant code directory is only 20 MB (30MB on disk, 3587 files).

What I need to know is what causes the development machine's cpu to go crazy for a full hour to download 20 MB worth of files from the server? Is SourceSafe responsible or SourceOffSite? Is this normal? Is there something I can do to change this?

[Beth]

Assuming that you are remote from the network, is there someone onsite with VSS and SOS that can try a get from inside the network?

Can you tell me which automation component version you use? Instructions for how to find that are posted here: How to determine the version of the VSS automation component.

While you are in the same registry area where the automation component is registered, can you tell me what the threading model is set for?

[GrandPixel]

I am actually inside the local network. Network utilization is typically < 1%.

SSAPI.DLL version is 6.0.98.48.
ThreadingModel is "Both".

[GrandPixel]

Please let me know if you have ideas. Thanks very much.

[Beth]

I'm attempting to reproduce what you have to help troubleshoot this.

[GrandPixel]

Thanks Beth. I am gone for the weekend. I appreciate your help. Let me know if you need any information from me.

[Beth]

I increased my repository up to where I think I have somewhere between 2000 to 3000 files. It took less than 10 minutes to perform the Get. My resources weren't very high. It's a VM with only about 512 mb RAM.

What happens if you try performing the same Get on the server machine that SOS is on?

[GrandPixel]

Well, the SOS server machine doesn't have visual studio on it. But I could do a get directly from my development machine's SOS explorer, just to see if it has the same problem as a "get from source control" from VS. In that case a recursive get from the SOS server machine would be an effective test. However, I don't see the SOS explorer even on the SOS server machine. Is it possible that's not installed on there? Would it hurt anything to install it on there?

[Beth]

Can you compare a Get using your SOS client on your client machine? Does that differ that much from performing the Get from inside Visual Studio?

An SOS client is not automatically loaded with the SOS server. It shouldn't hurt anything to have a client on the same machine.

[GrandPixel]

A Get on my client machine with SOS client does not use much CPU power compared to a Get in VS. It takes 7 minutes compared to roughly an hour. However, the way things are configured, it is not getting exactly the same files; I think it is actually getting more data with SOS client.

So I don't know why it takes so long with VS. Apparently it has something to do with the heavy CPU load. Is anything lost if I do my gets with SOS client instead and then open the solution in VS? Any differences in what ends up on the machine, etc?

[GrandPixel]

When I open in VS the solution for which I did a Get in SOS client, it says:

The solution appears to be under source control, but its binding information cannot be found. It is possible that the MSSCCPRJ.SCC file or another item that holds the source control settings for the solution, has been deleted. Because it is not possible to recover this missing information automatically, the projects whose bindings are missing will be treated as not under source control.

Then it gives me a prompt with 2 choices:

The associated source control plug-in is not installed or could not be initialized.
Temporarily work uncontrolled
Permanently remove source control association bindings

I choose temporarily work uncontrolled, and the solution continues to open and does not take long. But of course now I am not under source control. So I close the solution, and do open from source control. It says:

The local folder you chose to store your solution contains one or more solution files that have the same name as those in the source control server folder.

I choose overwrite, and it gives me this message:

The binding information for this solution could not be retrieved from its source control provider. This solution may have been placed under source control with a different provider configuration from the current one.

To keep source control working for this solution, Microsoft Visual Studio will now check out the solution file so that the binding information can be saved in it. However if the check out fails and the solution is closed without saving, the next time it is opened, the solution file will no longer appear to be under source control.

After I continue, the solution continues to open, taking about a minute with some CPU usage. The solution file is now checked out, but I do not want to change anything in the repository just yet so I am undoing checkout while not overwriting my local solution. Now when I close and open the solution again, it just opens and is under source control.

It seems to me like it would work to do a get from SOS client, and then choose open from source control in VS and change the bindings and check in the solution. However, I don't understand what happens behind the scenes, how everything is configured for our solutions, and if there are things that would be changed or broken if I do this.

Now I go back to the thought that it would be easier to just find out what causes open from source control into an empty directory to take an hour to begin with. If I can fix that, I wouldn't have to worry about problems that could occur if I change the get procedure and bindings, etc.

What would your suggestion be?

[Beth]

The binding issue could really be contributing to this. That is why I'd like to see if there was a difference in speed between performing the Get with the SOS Gui client and trying to get the project with Visual Studio. We have users who are bound to both VSS and SOS. We have a KB article posted here with instructions: Binding a solution to both SOS and VSS.

There will be two parts to what needs to be done:
1) Verify what is exactly causing the performance problem. This will be from trying a couple different Gets and comparing. Also, do any other users have this issue?

2) Fix your bindings which may simultaneously fix the performance problem, but at the very least will make working with SOS inside of VS much easier.

[GrandPixel]

I'm sorry for taking so long to reply. I would love to know if these lengthy get times (due to client CPU load) are normal for a get from within visual studio (vs relatively quick gets from within SOS client). And I would love to know for sure the cause of the problem. And I would love to be able to fix the problem for the team. However, I'm just a bit leery of modifying the bindings or any configuration settings that will change what is in our repository... simply because I'm no expert and don't really understand the changes I am making, and because we work as a team, I don't want to break anything.

Would you mind trying to provide me some confidence that performing this procedure will fix my particular problem? Or maybe you are not sure but this is just a troubleshooting step, but can give me some assurance that doing this would not have side effects that might disrupt development for the team?

Thanks Beth for your help thus far. I hope we can get this resolved.

[Beth]

I've helped users get their bindings set with no troubles. The one thing is that checking in binding changes will mean your other users will want to get those changes.

Maybe what would be better is if we work offline on this, then I can take a more direct look. Could you send an email to support at sourcegear.com (attn: Beth) with a link to this forum thread?