bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: xalloc.h (x2nrealloc): Don't always double the buffer size.


From: Jim Meyering
Subject: Re: xalloc.h (x2nrealloc): Don't always double the buffer size.
Date: Sun, 04 Feb 2007 12:14:42 +0100

Bruno Haible <address@hidden> wrote:
> Jim Meyering wrote:
>> I've just changed xalloc's x2nrealloc to do n = 3n/2, rather than n *= 2,
>
> Which means that the time needed for realloc() will grow by a factor of 1.7
> on average. If it matters - haven't measured it -, I would suggest to use
>    - n = 2*n for n < 1000000,
>    - n = 3*n/2 for n >= 1000000,
> so as to not penalize the frequent small allocations.

If you (or anyone) find a trend in applications where that slight
increase in the number of realloc calls makes a significant difference,
please let us know.  But bear in mind that having to *re*allocate is
relatively unusual.  Minimizing the cost of the much more frequent range
and overflow tests is important too.

>> -   In the following implementation, nonzero sizes are doubled so that
>> -   repeated reallocations have O(N log N) overall cost rather than
>> -   O(N**2) cost, but the specification for this function does not
>> -   guarantee that sizes are doubled.
>> +   In the following implementation, nonzero sizes are increased by a
>> +   factor of approximately 1.5 so that repeated reallocations have
>> +   O(N log N) overall cost rather than O(N**2) cost, but the
>> +   specification for this function does not guarantee that rate.
>
> How do you arrive at O(N log N) cost? I get
> O(N) + O(N/c) + O(N/c^2) + O(N/c^3) + ... = O(N) + O(log N) = O(N)
> where c is = 2 or = 1.5 respectively.

I didn't, but I should have noticed.  That comment was there before,
and I knew that changing a constant (c) would not affect big-O.

Thanks for the correction.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]