Sep 8, 2007 at 12:00 PM
I get very poor performance out of SVN bridge
I have an 8MB connection and all the other projects i use SVN (without svnbridge) for run really fast.
I rarely get over 500Bytes/s though SVNBridge
With other projects on SVN i get several MB/s
Are there any known issues?
Sep 8, 2007 at 1:14 PM
I'm getting the same behavior. I've recently started using it and SVN bridge is incredibly slow.
Sep 9, 2007 at 11:57 PM
500 bytes/second definitely doesn't sound right, I get significantly higher than that using SvnBridge. Is this during a checkout operation?
Sep 10, 2007 at 11:08 AM
Edited Sep 10, 2007 at 11:18 AM
Ok did some more analysis
For this project http://www.codeplex.com/ValidationFramework

Full get (Total file size 9.56 MB, Total files 562)
Tortoise and SVNBridge : 2min 58sec
Visual Studio 2005 (Source Control Explorer) : 30sec

View history of specific file
Tortoise and SVNBridge : 25sec
Visual Studio 2005 (Source Control Explorer) : 4sec

Check in a changed xml file (1.43 MB)
Tortoise and SVNBridge : 2min
Visual Studio 2005 (Source Control Explorer) : 9sec

Of course this is with me watching the windows clock tick over. So expect some inaccuracies.

Need any more information?
Sep 10, 2007 at 6:16 PM
Thanks for the information, this is very helpful. I did a checkout test of the ValidationFramework project using SvnBridge and it took between 40-50 seconds. In my case it was actually the CPU of my machine that was the bottleneck, but I'm on an extremely fast network.

On your checkout, what was your CPU utilization like? How many seconds did it take before the files starting coming down (i.e. before your TortoiseSVN window started displaying the files getting downloaded)?

It sounds like you have plenty of network bandwidth, and at 3 minutes I doubt it is your CPU that is the bottleneck like it is on mine, so I'm wondering if in your case the network latency is the cause? We can do some optimization around that if we know it's the cause.
Sep 10, 2007 at 10:00 PM
OK i have created an issue (So i have somewhere to upload files to)
Have a look at my cpu usage.
From that u can see that it is not cpu usage.
I have a T770 2.4GHz Core 2 Duo with 4GB of RAM so i would have been surprised if it was a problem with system resources.
When doing a full check out it is approx 50secs before the first item shows up in the tortoise window.
Sep 10, 2007 at 10:29 PM
Try the latest version to see how much it helps. We did some optimization for network latency so should make a difference for you.

Another thing to try is increasing the value of the "LOADING_THREADS" constant in the LoadAllFiles method in ReportHandler.cs. It might make a big difference in checkout times for you.
Sep 11, 2007 at 10:57 AM
OK with the latest source

Full get with LOADING_THREADS = 3
2min 30sec

Full get with LOADING_THREADS = 6
1min 30sec

View history of specific file with LOADING_THREADS = 6
13 sec

Check in a changed xml file (1.43 MB) with LOADING_THREADS = 6

So all faster except the checkin.
But still not as fast as Source Control Explorer
And note that increasing LOADING_THREADS to 6 did improve performance.
Sep 11, 2007 at 11:28 AM
It is a bit better but it still pretty slow (I only tested with LOADING_THREADS = 3).

FYI I'm in New Zealand, have a 10MB connection and a fast dual core CPU.
Sep 12, 2007 at 1:42 AM
Perhaps it's a latency issue. Where are you located, Simon?
Sep 12, 2007 at 3:19 AM
Sep 13, 2007 at 2:20 AM
I'm in the Pacific Northwest US, close to the TFS server, I suspect.

My speeds are quite fast - checking out ValidationFramework took 50 seconds or so.

I've noticed that the first several KB are always slow to very slow for any SVN server (with the exception of the server on my LAN). If I understand the DAV protocol SVN uses, it's quite "chatty" at the beginning, which would be very sensitive to latency. Crossing the Pacific (esp. if using a satellite) would kill throughput in much the way you are describing, if this is correct.
Sep 14, 2007 at 5:57 AM
I've found that doing the initial checkout is relatively fast but updating or committing takes much longer.
Sep 14, 2007 at 5:09 PM
@JamesNK -

That would also support the idea that it is latency which is killing the overall throughput: SVN doesn't have to compare much when doing the first checkout. It knows you need all the files of the version you requested, and just sends them without further ado. When doing updates or commits, it has to check each modified file, so there is more back-and-forth over the network.
Sep 15, 2007 at 3:16 AM
It's definitely the latency that is causing the big difference in performance for people far away from the servers. Many of the Subversion calls in the translation are turning into more than one TFS call, so the round trip time makes a big difference even if those calls take negligable processing time on the TFS server.

We've started optimizing it because the code is unnecessarily chatty with TFS in several places. It wasn't something we noticed ourselves since our round trip time is nothing and the extra calls take minimal server processing time.

Obviously when we deploy the server version of SvnBridge the problem goes away anyway because then there will be no latency between SvnBridge and TFS.
Oct 28, 2007 at 10:06 PM
FYI, I'm in southwest US with a business broadband (~10mbps down) and the speed is incredibly slow as well. I'm running Tortoise SVN 1.4.5 with the latest SVN Bridge as of 10/28/07. Browsing for diff in files seems pretty slow. Initial checkout of project took several minutes; the app doesn't seem to be as responsive as it should... Could someone elaborate on the THREAD_LOAD option mentioned earlier?

I'm browsing through the ValidationFramework as well.

Oct 30, 2007 at 6:51 PM
@pingmustard -

It's not the bandwidth which is the issue, it's the latency. You could be running at 10 Gbps from your ISP, and it would still be slow, since what is taking a long time is to get the bytes to you, not the size of the package.

The LOADING_THREADS option seems to have been refactored to allow a dynamic resizing of the number of threads servicing the request. For details, look at the ItemLoaderManager class in SvnBridgeLibrary\Handlers\ReportHandler\ItemLoaderManager.cs.
Jun 17, 2008 at 7:02 AM
I'm experiencing the same problems here at work and at home, I'm in Australia.

I'm finding that what happens to me is my disc goes absolutely crazy when I try and do something like view the log or see the revision graph, it takes a few hours before something comes up. SvnBridge ends up taking about 1.5GB of ram (I have 4GB in my machines) though the process is not using much CPU.

I've been working in read only mode with CompositeWPF, I have my own projects hosted on google code which are much more snappy with SVN.

Any ideas?
Jun 26, 2008 at 5:36 AM
The released version is using file base cache which has proven to be inefficient.
I suggest trying the latest version.
Jun 26, 2008 at 7:25 AM
No worries Ayende, I'll try checking it out of svn tonight and giving it a go :)