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

Stefan Fuhrmann <stefan2_at_apache.org> writes:

> Author: stefan2
> Date: Wed Sep 2 13:04:51 2015
> New Revision: 1700799
>
> URL: http://svn.apache.org/r1700799
> 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?

Regards,
Evgeny Kotkov
Received on 2015-09-02 15:33:57 CEST