On Thu, Aug 30, 2012 at 11:45 AM, Branko Čibej <brane_at_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
>>> <justin_at_erenkrantz.com> wrote:
>>>> On Tue, Aug 28, 2012 at 7:22 PM, Johan Corveleyn <jcorvel_at_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
Received on 2012-08-30 12:04:23 CEST