On Thu, Aug 30, 2012 at 11:45 AM, Branko Čibej <br...@wandisco.com> wrote: > On 30.08.2012 09:40, Daniel Shahaf wrote: >> Johan Corveleyn wrote on Thu, Aug 30, 2012 at 09:11:08 +0200: >>> On Wed, Aug 29, 2012 at 4:22 AM, Justin Erenkrantz >>> <jus...@erenkrantz.com> wrote: >>>> On Tue, Aug 28, 2012 at 7:22 PM, Johan Corveleyn <jcor...@gmail.com> wrote: >>>>> Yep, redirecting to a file eliminates the bottleneck (almost the same >>>>> as redirecting to NUL) (I ran it a couple of times to make sure the >>>>> server cache was hot): >>>> FWIW, I've historically seen similar behavior on Unix platforms as >>>> well - especially on machines with SSDs and a fast local network as >>>> the stdout I/O to emit the notifications is the slowest part of the >>>> system by far. -- justin >>> Hmz, so contrary to what I thought it seems it's not only a problem on >>> Windows. Is is as severe on *nix as on Windows? My export (w/ fast >>> server over a LAN) was twice as fast when redirecting notifications to >>> a file. Can somebody get some numbers on some unixy platform? >>> >>> But more to the point: anybody have a solution in mind? If it's not >>> Windows-only then some Windows defines wont help of course. >> Does not follow. Windows defines won't fix the Unix problem but might >> fix the Windows problem. > > And it would definitely complicate the build, because these functions > are in libsvn_subr and you for sure do not want to compile a separate > version of that for use by the cmdline client and other single-threaded > apps, just because we already know that output to terminal windows is > horribly slow on modern systems (compared to other bits). > It seems this performance issue is not related to locking in CRT: I've replaced svn_cmdline_puts with direct WriteFile API to stdout and got the same results. It seems the problem in other side that reads and display svn.exe output.
-- Ivan Zhakov
