Poor performance somewhere when adding/deleting files

tomt84 · Post by **tomt84** » Thu Oct 05, 2006 5:45 am

Hi

We have a large web application project in ASP.NET 2.0 in Visual Studio 2005 which is under source control with Vault.

When deleting or adding folders with lots (3000-4000+) of files and subfolders in, VS2005 never completes the operation, instead it sits there eating 100% CPU. Sometimes you get a bubble appear from the system tray saying "Visual studio is busy completing an internal operation" or similar.

Before it hangs, resource manager in Vista shows first that devenv.exe is doing a load of operations on the master file table, then that devenv.exe is talking to the source control server (same LAN, 100Mbits) for a while at about 2-3MB/minute, so something's happening. Then it hangs on 100% CPU with no disk or network activity. We've waited it out for about half an hour - we have 3500 files to delete.

Crashing out of VS reveals that the deletes didn't actually happen.

If you delete just a single subfolder with perhaps 20 files in it, it completes, but takes at least 2-3 seconds per file if you average them out. That's crazy. One might assume that VS would del

This has been an issue under XP Pro, Vista Beta 2 and RC1, and with Visual Studio 2005 both un-service packed and with SP1 beta installed.

It's also only an issue when the project is source-controlled.

Any ideas?

Thanks
Tom

Beth · Post by **Beth** » Thu Oct 05, 2006 7:23 am

Currently we haven't tested against Vista so we're not yet supporting that OS. When you stated you had the same issue on an XP machine, so you mean that you had the server set up there and the SQL server? If so, then if it can be reproduced there then I could review the log files working from there. You can put the client and server on the same XP machine for testing pursposes for this scenario.

Not counting in the OS you are using, this issue was seen in a previous user when they were trying to go from VS2003 to VS2005, but that was a VS issue because the projects didn't seem to like the upgrade.

tomt84 · Post by **tomt84** » Thu Oct 05, 2006 7:30 am

Okay, let's assume we're on XP given that we have the same performance issue on there. Forget I ever mentioned Vista (although we need to write our software with/on Vista from the start, so not supporting software devs on a Vista release candidate is IMO short-sighted)

Server is on IIS6 on Small Business Server with SQL Server 2005 installed. It works fine.

Client (let's go with the XP workstation) is XP Pro SP2 with Visual Studio 2005 and Vault 3.5.0.4741 client and server. They're on the same 100Mb LAN, no other significant traffic. It works absolutely fine for all other operations. Just very very slow when doing operations with large volumes of files/folders.

The high CPU usage is on the client, not the server.

(The other client (on Vista) is experiencing precisely the same issues as the XP box.)

Beth · Post by **Beth** » Thu Oct 05, 2006 8:08 am

Can you let me know which process in your task manager is showing the high cpu usage?

tomt84 · Post by **tomt84** » Thu Oct 05, 2006 8:08 am

devenv.exe on the client.

Beth · Post by **Beth** » Thu Oct 05, 2006 8:57 am

Can you enable IDE logging and reproduce the scenario and send me the log? You can use the private function here or send an email to support at sourcegear.com and reference this thread.

This probably has nothing to do with it, but are you using shadow folders?

tomt84 · Post by **tomt84** » Thu Oct 05, 2006 9:02 am

Sure, I will do at the next opportunity.

Not using shadow folders on the client, no. Am I right in thinking Vault has its own shadowing feature that you would have to enable, to qualify as "using shadow folders"?

We do have the folder shadowing feature turned on for shared folders on the server, accessed through right-click ->properties-> previous versions tab, but this isn't touching the working folders local to each client here.

Thanks.

Beth · Post by **Beth** » Fri Oct 06, 2006 9:26 am

Yes, the shadow folders is not run by default. It would need to be configured.
I doubt what you shared from the server would be adversely affecting the client. One way to check is to install a client on the server itself and perform the same tasks. Is the high CPU usuage happening on every client?

tomt84 · Post by **tomt84** » Sat Oct 07, 2006 5:21 am

Not had chance yet to reproduce the issue here with logging.

But yes, it's the same on every (well, both) client machines.

Unfortunately installing Visual Studio on to the server is not an option. There's no high CPU usage when doing the same operation from the Vault GUI client.

I've put a .zip of the particular folder tree that's causing the slowdown on our website:

http://edgebyte.com/files/folders/public/entry108.aspx

Perhaps you could download that, extract it, then drag it into a Visual Studio 2005 source controlled web application project, check it all in, then try deleting that folder from the source tree.

It takes my 3.2Ghz P4 HT with a gig of RAM at least 2-3 hours to delete that folder tree from the project. Deleting the whole lot at once has caused VS to just stop responding. Deleting it sub-folder by sub-folder is the way to go but again it takes silly lengths of time to do this.

This is across a flat OS install, and also across all (both) of our dev machines.

Thanks
Tom

Post by **jclausius** » Sat Oct 07, 2006 6:31 pm

Tom:

I believe the current release of Vault's Visual Studio IDE Client does not delete an entire folder, but rather deletes everything file by file. So if you thousands of files, the Vault IDE client is issuing thousands of delete file transactions.

There is no good news for Visual Studio 2003 as there are no APIs which support deletion of folders from a project. The files will still be deleted one by one - a very lengthy process considering the number of files you are talking about.

As for Visual Studio 2005, we recently discovered an undocumented call that will allow the Vault IDE client to delete a folder. This will be included in a maintenance release of Vault 3.5.

Until then, the best way to delete folders from Visual Studio projects is to remove them from the project, and the delete the folders from within the Vault GUI client.

HTH

tomt84 · Post by **tomt84** » Sun Oct 08, 2006 2:51 pm

Hi

Did you manage to reproduce those symptoms with that archive I sent over?

Good to know there's a fix on the way, any ideas when that might be released?

Thanks

Tom

Post by **jclausius** » Sun Oct 08, 2006 9:28 pm

tomt84 wrote:Did you manage to reproduce those symptoms with that archive I sent over?

Sorry, I do not know what Beth's status is on the problem. I just happened over the thread this weekend, and had some insight from a coding standpoint.

tomt84 wrote:Good to know there's a fix on the way, any ideas when that might be released?

No. At this point, we're identifying/documenting areas in the MSSCCI which are not working according to the Microsoft spec. Our coding stage hasn't even started.

tomt84 · Post by **tomt84** » Mon Oct 09, 2006 2:33 am

Okay, fair enough, thanks.

Give us a shout if you want us to test this particular feature whenever it becomes available.

Beth:
Please could you outline with some more detail exactly what you believe the best procedure is to delete large folder structures.

(We use Telerik's RadControls suite which is fairly regularly updated, and they ship with a folder that can contain a really large number of files that need replacing with every update. Not good if it takes us half a day to apply an update, so it's a big issue for us.)

Thanks

Tom

Beth · Post by **Beth** » Fri Oct 13, 2006 3:07 pm

Hello Tom,

As I've been working with the files you sent, I didn't have a problem deleting them. I added them to a VS project and then removed them. I want to try a few more things yet, but as all my machine resources are currently being used by another big process I will have to wait until the resources are free.

As far as recommendations, I'd say the same as Jeff.

tomt84 · Post by **tomt84** » Fri Oct 13, 2006 3:33 pm

How long did it take to add/remove those files, may I ask?

I presume that you checked them in before you tried to delete them?

Can I perhaps send you a copy of that repository so you can do the same thing against some working data?

It's still a major issue for us, this, and we've another service pack with a fresh set of files to apply due next week.