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

Re: Membuf "optimization" in r1532186

From: Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com>
Date: Tue, 31 Dec 2013 17:25:12 +0100

On Sun, Dec 22, 2013 at 2:52 PM, Branko Čibej <brane_at_wandisco.com> wrote:

> On 22.12.2013 14:16, Stefan Fuhrmann wrote:
> >
> > On Mon, Dec 9, 2013 at 11:01 AM, Branko Čibej <brane_at_wandisco.com
> > <mailto:brane_at_wandisco.com>> wrote:
> >
> > To clarify, the most often used pattern where the initial membuf
> > size os
> > 0 is when normalizing UTF-8 strings, where we let the utf8proc code
> > determine how large the allocation has to be, based on its analysis
> of
> > the string; the only alternative is to allocate a far larger
> > buffer than
> > you can ever need, and incidentally making assumptions about how the
> > normalization is implemented. The extra allocation you introduced
> here
> > does not speed anything up; rather the opposite.
> >
> >
> > It is not an extra allocation. For 0 bytes we simply get a valid pointer
> > but the next allocation will return the same pointer. So, there is no
> > waste.

[Last post to this topic as this is *really* a minor change.]

How on earth do you know that? Do you have a crystal ball that tells you
> that there will be no intervening allocations from the same pool?

Even if the active block in the pool has been completely
allocated (zero free memory), allocating 0 extra bytes is
for free in the current implementation.

> Or
> another one that tells you what will happen to APR's pool implementation
> in some future version?

I obviously can't tell - except that a major point of the APR
pool design is to be space efficient at the cost of being
unable to de-alloc selectively. If it ever were to add some
per-allocation overhead, its size will still be small relative
to the actual data buffer size.

> (On the other note about apr_palloc taking less time than a mispredicted

> conditional jump ... you're assuming that the apr_palloc code is in the
> L1 instruction cache,

Which it will be in most cases. If it is not, the initial allocation
will prime L1I for the following re-alloc. In general, SVN has
quite high L1I hit rates, i.e. high temporal code locality.

> and you're assuming that everyone uses Intel Core
> processors

apr_palloc latency is dominated by L1D latency. The latter
is usually subject to the same design forces than pipeline
depth. Even for embedded PPC, 2xL1D latency <= branch
misprediction latency.

> — and that everyone uses the same compiler you do. None of
> the above is likely to be true, in general.)

Well, with a good compiler, constant propagation will make
the old special-cased membuf_create() than the new one
calling apr_palloc (even if the latter gets a constant prop
code variant as well). The resize code is the place where
we can skip a NULL check.

-- Stefan^2.
Received on 2013-12-31 17:25:52 CET

This is an archived mail posted to the Subversion Dev mailing list.