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

bodr...@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
_______________________________________________
gmp-devel mailing list
gmp-devel@gmplib.org
http://gmplib.org/mailman/listinfo/gmp-devel

Reply via email to