1

in glibc malloc.c for calloc() (precisely, public_cALLOc()) implementation, when it tries to 0 out the memory it is doing in two ways, if the number of bytes are greater than 36 then straight away memset() is called otherwise it put 0 bytewise specifically, something like this:

glibc-2.13/malloc/malloc.c


void * public_cALLOc()
{
 .....
 int_malloc();
 ...
 ...
 /* Unroll clear of <= 36 bytes (72 if 8byte sizes).  We know that
 contents have an odd number of INTERNAL_SIZE_T-sized words;
 minimally 3.  */
 ...

if (nclears > 9)
    MALLOC_ZERO(d, clearsize);   /* this is nothing but memset(d,0,clearsize) */
else {
    *(d+0) = 0;
    *(d+1) = 0;
    if (nclears > 4) {
      *(d+2) = 0;
      *(d+3) = 0;
      if (nclears > 6) {
         *(d+4) = 0;
         *(d+5) = 0;
      if (nclears > 8) {
     *(d+6) = 0;
         *(d+7) = 0;
     *(d+8) = 0; 
        }
       }
      }     
  ---------------------------------

the question is that why we do not directly do memset () for all, what is the need of this distinction.

thanks, Kapil

Kapil
  • 836
  • 2
  • 8
  • 20

1 Answers1

2

It's a performance trick. It saves a function call when doing the "raw" writes would be faster than that.

Mat
  • 202,337
  • 40
  • 393
  • 406
  • Right. That was bit intuitive, but the reason why 36 bytes only is the point in question – Kapil Nov 15 '11 at 13:31
  • Because they determined through profiling that doing more would be more expensive than calling `memset` (which itself has some interesting tricks on some targets). – Mat Nov 15 '11 at 13:34
  • and is there any basis for this ? – Kapil Nov 15 '11 at 13:40
  • What do you mean? If it's "does this actually improve performance", then yes for some applications, as with everything performance-related. – Mat Nov 15 '11 at 13:44