[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: Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com>
Date: Wed, 23 Apr 2014 12:38:32 +0200

On Mon, Apr 21, 2014 at 7:05 PM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:

> Hi Stefan,
> It's good time to make consistent in either way.

I agree that consistency is a goal in itself since it
improves maintainability (principle of least surprise).
That does not mean it would trump other goals, but
its utility extends far beyond mere aesthetics.

Where temporary read buffers should be allocated: on stack or in heap
> (pool)? I'm fine with both approaches, but I would like to make it
> consistent. What do you think?

I'd love to see them all allocated on stack but there
is a problem: the 3-way comparison functions use
3 of these buffers at a time which translates to ~200k
stack memory. You can't do that too often in a 1M
stack that is the default in VisualStudio, IIRC.

Since it is conceivable that we would like to increase
the buffer size even further in certain functions at some
point in the future, stack allocation is not future proof.
So, +1 on allocation in pools. Exceptions should not
be frowned upon but require a specific rationale.

-- Stefan^2.
Received on 2014-04-23 12:39:04 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.