_mp_alloc vs ALLOC

[Niels Möller]

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...

You'd also need a corresponding function _mpz_newalloc (if that's a good
name?) which is almost identical to _mpz_realloc, but uses free + alloc
rather than realloc.

And then the question remains, are there systems and C libraries where
free + malloc is significantly slower than realloc in common cases? I'm
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.
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.

(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).

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.