[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Re: TSVN slow merges (help!)

From: Joel Low <joel_at_joelsplace.sg>
Date: Sun, 15 Jun 2008 06:48:36 +0800

Hello Stefan,

One thing which potentially is of some use is the changes in compiler code generation across VC versions (You mentioned you used VC2008, svn project uses VC6). VC6 had no stack frame checking (/GS) and other security checks which may slow down execution. The other possibility is the use of exception handlers. I believe TSVN uses C++ for its UI and stuff, so cl may have assumed that the rest of the svn code (in C) would have exceptions applied to it. That will definitely add considerable amount of overhead. Even if the code was compiled as C, /EHa still generates code for __try/__except which would add the same amount of overhead. Finally, the last possibility will be the use of the safe C runtime library. The safe parameter validation et al will definitely contribute to processor overhead.

You didn't mention anything about CPU usage, so I'll assume that the CPU usage went up (and hence assume all of these)

Hope this helps.

Regards,
Joel

-----Original Message-----
From: Stefan Küng [mailto:tortoisesvn_at_gmail.com]
Sent: Sunday, 15 June, 2008 5:45 AM
To: dev_at_tortoisesvn.tigris.org
Subject: Re: TSVN slow merges (help!)

Jean-Marc van Leerdam wrote:
> Hi Steve,
>
> I fully appreciate the agony you must be going through. I am sure that
> if there is anyone that can find this, it will be you. I may miss the
> experience to be of help to you, but I do have some suggestions (see
> below). Of course you probably already thought about these, but I
> mention them just in case.
>
> 2008/6/14 Stefan Küng <tortoisesvn_at_gmail.com
> <mailto:tortoisesvn_at_gmail.com>>:
>
> Hi,
>
> Some of you may have read reports that TSVN is twice as slow when
> doing a merge than the svn command line client (RC9 from
> open.collab.net <http://open.collab.net>).
>
> I can reproduce this easily: the build script of TSVN also builds
> the command line client, so simply comparing that client with the
> one installed from open.collab.net <http://open.collab.net> shows
> the same effect.
> I've used the tool "timethis" to measure a simple (but useless) merge:
>
> timethis svn merge -r11761:11762
> http://tortoisesvn.tigris.org/svn/tortoisesvn/branches/1.4.x
> d:\development\SVN\TortoiseSVN --dry-run --accept postpone
>
> This results in a merge time of 2 min 37 seconds with the rc9 from
> open.collab.net <http://open.collab.net>, and 5 min 17 seconds with
> the command line client built myself with the TSVN build scripts.
>
> I've also recorded the network packets with WireShark: they're
> identical for both clients. The only difference is the time between
> recorded packets.
>
>
> Are the network packets distributed in the same way across the timespan?
> Or are there specific extra pauses when using your own command line client?

Yes, each packet sent from my own built client is sent a few miliseconds later. It's not just a few big pauses in between, it's between every single packet.

> How does the TSVN Gui perform this merge? Is it also 5 min 17, or is
> it much slower than that? --> If it's the same then the issue most
> likely lies in the SVN libraries.

It's the same as with my own built CL client. Also aroung 5:17.

> IIRC in the past TSVN (or the SVN linbraries, I can't remember) has
> had some issues with DLLs being loaded and unloaded frequently. Could
> that be the cause of the extra delays?

Already checked that. But the debugger doesn't show any dll loads or unloads during a merge (only when the command starts, but that's expected and has nothing to do with the delay).

Thanks anyway for your suggestions.

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.net
Received on 2008-06-15 00:48:56 CEST

This is an archived mail posted to the TortoiseSVN Dev mailing list.