Loading ...
Sorry, an error occurred while loading the content.

Re: [SPAM?]Re: Vim 7 performance notes

Expand Messages
  • Robert Cussons
    ... 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
    Message 1 of 4 , Feb 5, 2007
      George V. Reilly wrote:
      > Yakov Lerner wrote:
      >> 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
      >>> 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.
    Your message has been successfully submitted and would be delivered to recipients shortly.