Poor performance somewhere when adding/deleting files
Moderator: SourceGear
Attached: screenshot with the VS "internal operation" bubble.
All I did was drag the Combobox folder from a Windows Explorer window into the project tree.
If I remove the source control bindings from the project and do the same thing, it's near instant.
This particular machine is XP SP2, Visual Studio 2005, and is a dual processor Athlon MP 2100 wtih a gig of ECC RAM.
In this instance, there is no CPU spike and no significant HDD activity. I've been waiting 15+ minutes so far.
The folder I dragged on to the tree contains 114 files and 21 folders.
All I did was drag the Combobox folder from a Windows Explorer window into the project tree.
If I remove the source control bindings from the project and do the same thing, it's near instant.
This particular machine is XP SP2, Visual Studio 2005, and is a dual processor Athlon MP 2100 wtih a gig of ECC RAM.
In this instance, there is no CPU spike and no significant HDD activity. I've been waiting 15+ minutes so far.
The folder I dragged on to the tree contains 114 files and 21 folders.
- Attachments
-
- vs_slow.png (86.61 KiB) Viewed 10050 times
Tom Fanning
I have reported this as an issue on Microsoft Connect at this URL:
https://connect.microsoft.com/VisualStu ... kID=226078
https://connect.microsoft.com/VisualStu ... kID=226078
Tom Fanning
I'm sorry, Beth, but I was under the impression that we have a support contract with Sourcegear.
This is a *major* issue for us, which wastes a significant amount of time most weeks and totally halts our development while we wait for (what appears to be) Vault to finish whatever it's doing.
If you personally don't have the resources handy to follow this up, is there not anyone else that does support who does have resources available?
Thanks.
This is a *major* issue for us, which wastes a significant amount of time most weeks and totally halts our development while we wait for (what appears to be) Vault to finish whatever it's doing.
If you personally don't have the resources handy to follow this up, is there not anyone else that does support who does have resources available?
Thanks.
Tom Fanning
I don't have the exact time on those files. The environment I performed it in though was with VMWare and had up to 4 servers running at once on my machine.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?
Yes, they were checked in.
Again, you can feel free to send a copy of the repository. It can be uploaded to ftp.sourcegear.com\incoming. Please name it something unique so that I can pick it out of the other files. You won't be able to see other customer's files there to tell if you named it the same as someone else's or not. I am working on getting more space open for this.
I think there may have been a misunderstanding. What I was trying to say was that despite all that I've had running on my machine, the deletion of the files came off without a hitch. (Sorry, wasn't belly-aching about the work. I love my job. I just don't have a 5-minute answer.)
I am going to try to catch a time on the delete without so much stuff running. I will allocate only 1 GB of RAM to the virtual machine I'm using for yours. I don't think there is any chance of reproducing the behavior with just the files alone because there are other factors that can figure into the slowdown such as the amount of branching and shares, size of database, is shadow folders are being used, etc.
I am going to try to catch a time on the delete without so much stuff running. I will allocate only 1 GB of RAM to the virtual machine I'm using for yours. I don't think there is any chance of reproducing the behavior with just the files alone because there are other factors that can figure into the slowdown such as the amount of branching and shares, size of database, is shadow folders are being used, etc.