subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Evgeny Kotkov <>
Subject Re: svn commit: r1700799 - in /subversion/trunk/subversion: include/svn_io.h libsvn_subr/stream.c svnadmin/svnadmin.c svnfsfs/load-index-cmd.c tests/libsvn_subr/stream-test.c
Date Wed, 02 Sep 2015 13:33:31 GMT
Stefan Fuhrmann <> writes:

> Author: stefan2
> Date: Wed Sep  2 13:04:51 2015
> New Revision: 1700799
> URL:
> Log:
> [Combines r1698359 and r170078 into a single commit for better review.]
> Introduce a stream wrapper object that adds buffering support to any
> readable stream.  Use it on the stdin streams in our CL tools.
> As it turns out, parsing data from a stdin byte-by-byte incurs a
> massive overhead of 100% internal and 300% system load over a buffered
> stream.  'svnadmin load-revprops' sees a 5 times speedup if all data
> is in OS disc caches.  This is a realistic assumption in a "final sync
> and switch over to new repository" scenario.
> The other 2 uses of stdin either have less data to process (svnfsfs
> load-index) or parse only a small fraction of the stream (svnadmin load).
> * subversion/include/svn_io.h
>   (svn_stream_wrap_buffered_read): Declare the new stream constructor API.


If buffering makes difference for how well svnadmin load, load-revprops and
svnfsfs load-index behave, can't we use the standard mechanism for that,
say, apr_file_open_flags_stdin(..., APR_BUFFERED)?

What is the point of reimplementing something that's already a part of the APR?

Evgeny Kotkov

View raw message