_mp_alloc vs ALLOC

[Torbjorn Granlund]

bodrato at mail.dm.unipi.it writes:

  Ciao,
  
  Il Ven, 24 Febbraio 2012 10:40 am, Torbjorn Granlund ha scritto:
  > I cannot see how TMP_ALLOC_LIMBS_2 could save *anything* for small
  
  I'm not sure I agree with Torbjorn. Nevertheless developers time is a far
  more precious resource than a few cpu cycles or bytes of code size...
  That's why I completely change my question, always about allocations.
  
  
  I always used the MPZ_REALLOC macro, to enlarge (if needed) the memory
  area available for an integer. This macro gives a (possibly new) pointer
  with the requested size available... but it also copies the content.
  
  Sometimes I know in advance that the content can be discarded. Is there a
  standard way to ensure a given size without moving data?
  
I use this trick for that:

  rp = realloc (rp, 1);
  rp = realloc (rp, newsize);

I suspect there is a lot to win from using such a trick, at least of the
old size was large.  But perhaps some malloc implementations are so slow
for finding a 1-byte block that it can also become slower?  (It is a
pity the C library provide only very primitive allocation functions.)

I am not sure how to deal with this in GMP.  We could add a flag field
in MPZ_REALLOC, or have special functions+macros.

Unfortunatly, we are somewhat constrained by the replaceable allocation
functions; changing the __gmp_reallocate_func type will break
compatibility with user code.  We will therefore need to make two
realloc calls by invoking the fairly high-level __gmp_reallocate_func
twice.  Oh well.

-- 
Torbjörn