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

Re: Allocation of read buffers (was Re: svn commit: r1535686 - in /subversion/branches/log-addressing/subversion: include/svn_error_codes.h libsvn_fs_fs/transaction.c tests/libsvn_fs_fs/ tests/libsvn_fs_fs/fs-fs-pack-test.c)

From: Ivan Zhakov <ivan_at_visualsvn.com>
Date: Wed, 23 Apr 2014 16:38:45 +0400

On 23 April 2014 15:51, Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com> wrote:
>
> On Wed, Apr 23, 2014 at 1:18 PM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
>>
>> On 23 April 2014 14:50, Bert Huijben <bert_at_qqmail.nl> wrote:
>> > On Windows the default stacksize is 1 MB, and as we are in many cases
>> > ‘just
>> > a library’ we should try to be a bit on the safe side, especially when
>> > we
>> > call into other code -or are likely to be called from other code- that
>> > might
>> > have their own buffers.
>> >
>> >
>> > Until recently these buffers weren’t that big… Now that they are on
>> > trunk we
>> > should probably move them to a short lived scratch pool… or reduce them
>> > back
>> > to their original size.
>> >
>> I've vetoed increasing read buffer size recently and going to revert
>> r1586922: make SVN__STREAM_CHUNK_SIZE 16k again and implement
>> optimization and FSFS layer.
>
>
> Give me at least a chance to work through the backlog of
> issues to you raised before reverting stuff.
>
No problem. Anyway I was not going to revert your change completely: I
wanted reimplemented your dynamic compare buffer on FSFS layer instead
of generic stream.

-- 
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com
Received on 2014-04-23 14:39:37 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.