_mp_alloc vs ALLOC

[Marc Glisse]

On Thu, 31 May 2012, Niels Möller wrote:

> bodrato at mail.dm.unipi.it writes:
>
>> Do you mind if I define a new macro MPZ_NEWALLOC?
>> Currently it should be the same as MPZ_REALLOC, but it can be changed in
>> the future...
>
> To me it would make some sense to make it do something useful right
> away...

Assuming we can...

> And then the question remains, are there systems and C libraries where
> free + malloc is significantly slower than realloc in common cases?

I am afraid so. Experiments are needed, but my intuition tells me that for 
small numbers (for large numbers, the cost of copying in realloc is anyway 
small compared to whatever operation you are doing), free+malloc will be 
significantly slower than realloc.

> probably naïve, but if we consider the case that the current block can
> be easily extended in place, I imagine that free will put it at the head
> of the free list, and the subsequent call to malloc will get it back.

Allocators often try to separate allocations depending on their size. They 
will try to respect a realloc call, but if they can (free+malloc) they may 
prefer taking a block from another pool. Letting them do it may be a good 
thing in the long run (less fragmentation, future allocations are faster), 
but may be slower for this particular call.

Again, this is pure speculation, I may be way off.

> Then the additional overhead compared to realloc seems small, but I
> guess it could matter, e.g., if access to the free list is protected by
> a mutex.

I don't think many allocators still do that...

> (Speaking of allocation, I also wonder what to do about the problem
> described in
> http://gmplib.org/list-archives/gmp-devel/2012-January/002161.html,
> there were no replies at the time).

Good question ;-)

Related: I was always unhappy about the order of the reallocation function 
arguments. malloc and free can be used by gmp (just ignore the old size 
passed as last argument) but realloc needs a wrapper.

-- 
Marc Glisse