[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: notification output bottleneck

From: Justin Erenkrantz <justin_at_erenkrantz.com>
Date: Thu, 30 Aug 2012 06:20:41 -0400

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.

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?

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
Received on 2012-08-30 12:21:15 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.