Bert Huijben wrote on Mon, Aug 27, 2012 at 02:09:07 +0200:
> > -----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.
>
Someone could write a single-threaded 'cat' tool (i.e., reads stdin and writes it
unmodified to stdout) that employs those #define's, then? And then pipe
svn's output through that.
(which is basically halfway to writing an xterm clone?)
> 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 about redirecting the output to a file?
> (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 13:10:23 CEST