Bert Huijben wrote on Mon, Aug 27, 2012 at 02:09:07 +0200: > > -----Original Message----- > > From: Johan Corveleyn [mailto:jcor...@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 >
