> -----Original Message-----
> From: Johan Corveleyn [mailto:jcorvel_at_gmail.com]
> Sent: maandag 27 augustus 2012 00:39
> To: Subversion Development
> Subject: notification output bottleneck
>
> I've never noticed this before (slow server, but now I'm testing a new,
faster
> server), but it seems that the writing of notification output on stdout is
a
> bottleneck for checkout, update or export on Windows (cmd.exe). With a
> fast server, hot caches, and everything on a Gb LAN, checkout of a large
> working copy is twice as fast (from 79 minutes down to 35 minutes) when I
> redirect output to NUL. I tested with both 1.7.5 (SlikSVN) and trunk, the
> results were about the same.
>
> Is there anything that could be done in svn to remove that bottleneck
> (buffering, ...)?
>
> (there might have been some discussion about this before, but I can't find
it)
I found this problem too while profiling.
The console apis on Windows in the Microsoft libraries are slow because they
try to be safe for multithreaded applications. There are some defines that
can be used to speed this up (which will avoid the most costly thread
synchronisations), but we can't just apply these to our code as that would
make libsvn_subr no longer multithread safe.
Using svn -q for checkout will certainly help to improve performance at the
cost of suppressing the output, as will using a different client that moves
the notification handling to another thread via a less expensive api (such
as AnkhSVN does).
In some cases redirecting the output of svn via a pipe will help, but I've
also found cases where this made it slower.
(What I haven't checked is if the profiler slows down the console IO more
than other operations. I wouldn't be surprised if it did. The defines didn't
provide the difference that I would expect)
Bert
Received on 2012-08-27 02:09:47 CEST