On Thu, Aug 30, 2012 at 12:20 PM, Justin Erenkrantz
<justin_at_erenkrantz.com> wrote:
> On Thu, Aug 30, 2012 at 3:11 AM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
>> 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. Buffering
>> the output may be the only way to eliminate this bottleneck? What are
>> the pros and cons, and how hard would that be? Any other ideas?
>
> You *could* change the notification system to emit in batches rather
> than print a line per-item as invoked. But, that might not be worth
> it...from a usability perspective, we're likely not going to want to
> write to the console in blocks of say 100 if the console screen height
> is 25. IIRC, in my analysis on Unix (where which shell you were using
> had a noticeable impact), the time it takes to write 25 lines was the
> same as writing 1 line - my hunch is that it's the same on Windows as
> well.
Yes, I think it's the same on Windows. I just read a bit about Stream
I/O on Windows, where it says [1]:
"Files opened using the stream routines are buffered by default. The
stdout and stderr functions are flushed whenever they are full or, if
you are writing to a character device, after each library call."
I guess that means that the buffer is flushed after each call to
fputs, i.e. after each invocation of svn_cmdline_puts, i.e. per line.
So there is just too much flushing going on :-).
> The best approach here may be to clearly document it somewhere - if
> there truly is a human driving the CLI, then they can make a decision
> if they want to redirect to a file or something...but, then what
> happens when we go into interactive conflict resolution mode?
Even if we document it abundantly, a lot of users will not find out
that they simply have to redirect output, or use the -q option, to get
a huge performance boost. It's not the default.
> Another approach is to split out the notification writes to a
> different thread...it'd stop the blockage issue. Fun...but, I don't
> think we're using threading anywhere in the client right now... --
> justin
But won't the output thread then take just as long, so the user still
has to wait until that is finished? There is not much point (from the
users perspective) in having the checkout finished after 25 minutes,
if the output still keeps coming in for another 25 minutes...
[1] http://msdn.microsoft.com/en-us/library/c565h7xx.aspx
--
Johan
Received on 2012-08-30 13:02:56 CEST