Probably because they wanted to simulate calling a function that parsed a string, and such functions will have to allocate and deallocate memory as needed.
It's also worth noting that calling malloc and free in a tight loop where you're always requesting the same amount of memory will be pretty fast. Good implementations of malloc - of which glibc certainly is - will consistently return the exact same chunk of memory to you, and you will be on the fast-path of the allocation algorithm.
You're looking at this from the wrong angle. You're looking at the C code and thinking, "How can I optimize this?"
What you need to do in this case is look at it and say, "How can I optimize this and still retain the essence of what I want to test?" Your optimizations remove that essence - if you're calling a function that is a part of an API, it will have to allocate and free its own memory. That the code is in a loop is an artifact of the experiment.
I'm looking at it from the angle of someone that has spent over a decade in and out of C. The code in the loop is in NO way an "artifact", it's absolutely critical to the comparison. My example in no way removes the essence, especially if we are using "idioms".
I said the loop is an artifact, not the code in the loop. Their experimental design is "Do xN times, then divide the overall runtime of the program by N to estimate the cost of x." If timing a program that did x once lead to good results, they would do that - but it doesn't, so they don't. You're trying to optimize around the loop, but by doing that, you're changing the x that is being measured.
Two things potentially different between the two implementations:
1. The C code is stack allocating a pointer in every loop iteration.
2. Cleaning up the memory without(potentially) triggering Python's GC.
Is the Python GC getting triggered in this scenario? If not, then this is what's actually happening, with the cleanup happening automatically when the process exits:
char x[10000000];
int i;
for (i = 0; i < 10000000; i++) {
x[i] = malloc(44 * sizeof(char));
sprintf(x, "%d %d", i, i);
}
If GC is thrown into the mix, the C code is really:
char x[1000];
int i;
int j=0;
for (i = 0; i < 10000000; i++) {
x[j] = malloc(44 * sizeof(char));
sprintf(x, "%d %d", i, i);
j++;
if(j == 1000) {
for(j = 0; j < 1000; ++j)
free(x[j]);
}
}
If by x you mean performing a string operation and copying the result to memory .. I still fail to see how allocating and deallocating memory on each iteration is a fair comparison, it's not something I'd expect a competent C developer to do ergo how is that a relevant comparison?
I know the aim is to show off the string operation in and of itself so why not leave it there, why the need to bring garbage collection into the mix?
Edit: it's the way the garbage collection has been thrown into the mix I'm having difficulty understanding the need for.
It's also worth noting that calling malloc and free in a tight loop where you're always requesting the same amount of memory will be pretty fast. Good implementations of malloc - of which glibc certainly is - will consistently return the exact same chunk of memory to you, and you will be on the fast-path of the allocation algorithm.