¿Por qué la macro '#define alloc_nr (x) (((x) +16) * 3/2)' se usa en muchos files cache.h?

He visto la siguiente macro utilizada en muchos files cache.h:

#define alloc_nr(x) (((x)+16)*3/2) 

Aquí hay un ejemplo.

Sé que se usa para boost el tamaño del búfer asignado cuando el búfer está casi lleno. El buffer crecería aproximadamente 1.5 veces su tamaño actual. Es por eso que se usa *3/2 3/2. Pero ¿por qué se agregan 16 extra? La macro se convirtió en x*1.5+24 cuando se expandió. ¿Hay alguna razón en particular para esta macro? ¿Por qué a todos les gusta usar esto?

Si el valor inicial es 0, quiere alloc_nr(0) para dar un número estrictamente positivo (24 aquí). Sin el 16 sería 0. Quiere que alloc_nr(x) sea ​​mayor que x (y no demasiado cerca de x para evitar reasignaciones demasiado frecuentes).

Los numbers particulares 16 y 3 y 2 no son muy importantes (la relación 3/2 es más significativa).

Esto probablemente ayudará (de http://lxr.free-electrons.com/source/tools/perf/util/cache.h#L38 )

 41 * Realloc the buffer pointed at by variable 'x' so that it can hold 42 * at least 'nr' entries; the number of entries currently allocated 43 * is 'alloc', using the standard growing factor alloc_nr() macro. 44 * 45 * DO NOT USE any expression with side-effect for 'x' or 'alloc'. 46 */ 47 #define ALLOC_GROW(x, nr, alloc) \ 48 do { \ 49 if ((nr) > alloc) { \ 50 if (alloc_nr(alloc) < (nr)) \ 51 alloc = (nr); \ 52 else \ 53 alloc = alloc_nr(alloc); \ 54 x = xrealloc((x), alloc * sizeof(*(x))); \ 55 } \ 56 } while(0) 57 

Usted comprende el *3/2 . El +16 garantiza que crece al less en 16 objects (sea cual sea el sizeof *x ) cuando el búfer sea pequeño. Se debe lograr un equilibrio en no desperdiciar demasiada memory y evitar demasiados realloc individuales. Cuando el buffer es pequeño, desperdiciar 'grandes múltiplos' de la memory buffer no es un problema. Por ejemplo, si solo usara *3/2 , un buffer de 4 objects solo crecería a 6 objects. En particular, sin este crecimiento, un buffer de input cero en realidad no lo haría crecer. Es mucho mejor perder algo de espacio y crecer más rápido (en términos relativos) cuando el buffer es pequeño.