George V. Reilly wrote:
Yakov Lerner wrote:
On 2/4/07, Yakov Lerner <[EMAIL PROTECTED]> wrote:
On 2/4/07, Alexei Alexandrov <[EMAIL PROTECTED]> wrote:
> >
> > Gnu malloc (glibc) is exceptionally fast, iirc. It is possible
> > to benchmark the malloc speed during the ./configure time.
> > And auto-select the initital size depending on the results.
> >
> > The procmail this similar technique in configure: It automatically
> > benchmarks it's own builtin strstr() vs system's strstr() and
selects
> > the one which is faster.
> >
>
> In this particular case the speed of malloc is not the only factor.
> Big fraction of time is spent in memset() while initializing the array
> with zeros.
That's why I thought that it's reasonable to benchmark malloc()
relative to the time it takes to memset() that same area. (When
benchmarking, you need to know what to compare it to). If you
compare time it takes to malloc N bytes to the time it takes
to memset() same N bytes, you can tell the speed of malloc
*relative* to the time of memset()ting same size. So you will
automatically know which one is realtively more expensive,
the memset() or the malloc().
And then maybe the optimal initial size will be size where
memset() time is equal to the malloc() time ? The break-even,
so to say, in which neither of two time dominates the other ?
memset() is an O(N) operation. Its running time has to be proportional
to N because it has to touch every single byte. If the pagefile gets
involved, it's still O(N), but with a much larger constant.
malloc()'s running time is much harder to say anything about. Not only
can it vary widely between different implementations, it also depends
upon the state of the system. Is the heap fragmented? Is it suffering
from lock contention? (Not a problem with single-threaded apps like
Vim.) Is the memory already in the process's working set, or does malloc
have to ask the OS for more pages? Is the system under intense memory
pressure and will the malloc() operation cause paging to disk? Finally,
malloc(N) is probably independent of N. It has to find a free entry of
size N in its data structures, which is very dependent on both the
implementation and the preceding factors. Benchmarking malloc() in
./configure is not likely to tell you very much about its performance in
a workload you care about.
Sorry to butt in here, but I had a question about all this discussion on
malloc. If you are talking about the C function malloc which I think you
are as you referred to glibc, then as far as I am aware, malloc does not
zero the memory that is allocated, it merely allocates it, so I do not
see where memset would be used. calloc on the other hand, also zeros the
memory that it allocates. Sorry if I am completely misguided but just
interested to know other people's thoughts on it.
Cheers,
Rob.
