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

Re: [PATCH] Flush stdout more often

From: Peter N. Lundblad <peter_at_famlundblad.se>
Date: 2006-02-11 23:05:33 CET

On Fri, 10 Feb 2006, Justin Erenkrantz wrote:

> On 2/10/06, Garrett Rooney <rooneg@electricjellyfish.net> wrote:
> > I can't imagine that the flush is going to even show up in profiling...
>
> It's an extra syscall for every line of output (imagine redirecting
> stdout to a file!). We've never needed it before...
>
Justin,

I just checked out a copy of trunk from the svn repository. That produced
1367 lines of output and strace reports 123426 syscalls (that's the number
of lines output by strace). So, in the case where fflush *is* an extra
syscall per line, would you mind estimating the actual overhead in time?
(This is a rethorical question, sorry). I think this is microoptimization.

Note that we already have a fflush (per character) when we output the dots
while transfering files, because we want the dots to show up immediately.

> > And as for not intending the command line program to produce parseable
> > output, it's the second to last thing on our list of features on
> > subversion.tigris.org.
>
> There's a point that if a developer wants to write a tool on top of
> SVN, they should be using the bindings not asking us to make changes
> in our command-line program so their tool works better. -- justin
>
As others pointed out, being script friendly is important. Why do we
otherwise have a locale-independent date in the log output (and the number
of lines in the log message printed)?

Regards,
//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Feb 11 23:05:59 2006

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.