On Mon, Aug 27, 2012 at 2:09 AM, Bert Huijben <b...@qqmail.nl> wrote: >> -----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.
Interesting. Am I correct in saying that this is really only a problem for the commandline 'svn' client (and perhaps 'svnadmin' and 'svnlook' etc ...)? Other clients can do their own fast notification handling, right? And Isn't 'svn' always single-threaded? In that case: couldn't we make the necessary multithread-unsafe, but fast, output functions for 'svn' only? > 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). Yes, using -q is a workaround. It's usually good. But then every once in a while something chokes, and you want to know what the last file was etc ... So having the output be fast would be better :-). -- Johan