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.
Bert
From: Stefan Fuhrmann [mailto:stefan.fuhrm...@wandisco.com]
Sent: woensdag 23 april 2014 12:39
To: Ivan Zhakov
Cc: Subversion Development; Stefan Fuhrman
Subject: 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)
On Mon, Apr 21, 2014 at 7:05 PM, Ivan Zhakov <i...@visualsvn.com
<mailto:i...@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.
