Why leaking memory is slower than doing delete[] on the dynamic array

Question

I just started using google benchmark for microbenchmarking and I got results I can't really explain. I have a function URLify(basic functions that encodes whitespaces). I convert my string to char * and pass it to the function

This is how I test it using google benchmark and Full optimization. using VS 2015 x64

while (state.KeepRunning()) {

    char* ch = new char[str.length()*2 ]; //str is a string I want to encode
    memcpy(ch, &str[0], str.length() + 1);  
    URLify(ch, str.length());
    delete[] ch;
}

this is the results doing 30000 iterations and 5 repetitions


BenchURLify/iterations:30000/repeats:5                    5370 ns         5729 ns        30000
BenchURLify/iterations:30000/repeats:5                    5366 ns         5208 ns        30000
BenchURLify/iterations:30000/repeats:5                    5349 ns         5208 ns        30000
BenchURLify/iterations:30000/repeats:5                    5364 ns         5729 ns        30000
BenchURLify/iterations:30000/repeats:5                    5356 ns         5208 ns        30000
BenchURLify/iterations:30000/repeats:5_mean               5361 ns         5417 ns            5
BenchURLify/iterations:30000/repeats:5_median             5364 ns         5208 ns            5
BenchURLify/iterations:30000/repeats:5_stddev             8.48 ns          285 ns            5

But when I removed delete[] from the code google benchmark showed different result and not the result I expected. I thought freeing memory every iteration would be slower than leaking memory. But this is the results without delete[] ch

BenchURLify/iterations:30000/repeats:5                    7240 ns         7292 ns        30000
BenchURLify/iterations:30000/repeats:5                    7245 ns         7292 ns        30000
BenchURLify/iterations:30000/repeats:5                    7116 ns         7292 ns        30000
BenchURLify/iterations:30000/repeats:5                    7091 ns         7292 ns        30000
BenchURLify/iterations:30000/repeats:5                    7116 ns         6771 ns        30000
BenchURLify/iterations:30000/repeats:5_mean               7162 ns         7188 ns            5
BenchURLify/iterations:30000/repeats:5_median             7116 ns         7292 ns            5
BenchURLify/iterations:30000/repeats:5_stddev             74.6 ns          233 ns            5

So my question is why doing delete[] shows better performance than leaking memory? or what am I missing here

Perhaps faster to use memory in the cache than allocating new memory off the heap? Perhaps the heap manager recycles recently used memory instead of doing more bookkeeping for carving memory out of the heap? — Eljay, Apr 19 '19 at 16:15

score 3 · Answer 1 · answered Apr 19 '19 at 16:16

There are many possibilities.

The test is flawed and the timings don't mean what you think.
When the memory is freed the runtime can allocate the same block to you each time. But when not freeing the memory the runtime has to allocate a new block which can take time and may have to allocate more memory from the OS (depending on how the memory allocation is working in your specific environment).
Many more.

score 3 · Accepted Answer · answered Apr 19 '19 at 16:19

The delete[] function is doing very little and will be extremely fast. The system will likely keep returning the same memory on each iteration and can all be done in userspace ( what happens in the kernel during malloc? has a lot more details).

Memory is allocated to your process in blocks. If you let the memory leak you will at some points need to extend memory space using a kernel call. These kernel calls are likely to be much more expensive than the delete calls.

Why leaking memory is slower than doing delete[] on the dynamic array

2 Answers2