Re: [SPAM?]Re: Vim 7 performance notes
- George V. Reilly wrote:
> Yakov Lerner wrote:Sorry to butt in here, but I had a question about all this discussion on
>> On 2/4/07, Yakov Lerner <iler.ml@...> wrote:
>>> On 2/4/07, Alexei Alexandrov <alexei.alexandrov@...> 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
>>> > > 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.
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.