Re: [Chicken-users] A more detailed plea for help with FFI...

[Ed Watkeys]

On Dec 16, 2004, at 6:51 AM, Tony Garnock-Jones wrote:

> Ed Watkeys wrote:
> > Running the code below with the set-finalizer! call in 1) place and 
> > 2) commented out resulted in a runtime delta of about eight seconds 
> > on my 1.33 GHz PB G4 12" running OS X 10.3.6. That means that the 
> > overhead of handling a finalizer call is about 80 microseconds, or 
> > about 0.00008 seconds. That's about 110,000 processor cycles. Wow.
>
> Alternatively, it means that malloc() and free() are really slow. 
> (Which hypothesis is supported by the fact that malloc() and free() 
> are actually really slow :-) )

It's not malloc(), because the test takes about 8 seconds less (for a 
total of about 0.2 seconds) to execute if I don't register the 
finalizer -- which simply falls free(). You know, what I said above.

It's not free() because the the run time of the slow version doesn't 
change if I comment out the free() in the finalizer function. (I 
performed this test yesterday but didn't mention it because my message 
was already too long.)

Regarding your slander of malloc() and free(), consider the following 
program:

#include <stdlib.h>
#include <assert.h>

#define N_BUFFERS 1000000 /* a million buffers */
#define BUFFER_SIZE 16 /* of sixteen bytes */

int main(int argc, char **argv)
{
  void **pp = (void **)calloc(N_BUFFERS, sizeof(void*));
  int i;

  assert(pp != NULL);

  for(i = 0; i < N_BUFFERS; i++) {
    pp[i] = (void *)calloc(1, 16);
    assert(pp[i] != NULL);
  }

  for(i = 0; i < N_BUFFERS; i++)
    free(pp[i]);

  free(pp);
}

It runs on my machine in about 0.8 seconds. Doing the math, that comes 
to about 1100 processor cycles per malloc()/free() pair. That's about 
one percent of the time delta.

Felix already has a pretty good suspect: finalizer dispatching code 
that does a linear search through a list.

Ed

--
Watkeys Product Design -- http://watkeys.com/