Joel Low wrote:
> 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)
Thanks for the hints.
The problem is that the CPU usage stays almost at 0% during the whole
merge. It's really only network related, not CPU related.
As it appears, with IPv6 disabled, it's only neon that's slow. A test
using serf instead of neon revealed the same speed as with the RC9.
That's however gone again once IPv6 is enabled again.
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Received on 2008-06-15 09:39:09 CEST