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.
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? Or
another one that tells you what will happen to APR's pool implementation
in some future version?
(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, and you're assuming that everyone uses Intel Core
processors — and that everyone uses the same compiler you do. None of
the above is likely to be true, in general.)
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane_at_wandisco.com
Received on 2013-12-22 14:53:15 CET