1

I have a block of memory that I want to re-allocate to a different size, but I don't care if the memory is discarded or not. Would it be faster to free() the memory and then malloc() a new memory block, or is realloc() the way to go?

I'm thinking that either solution is not optimal because extra work is performed. I'm betting that realloc() is faster in locating a memory block that is large enough, because of the possibility that the current fragment is large or small enough to hold the new memory block. But, if the fragment is not large enough, it has to copy memory which malloc() does not.

I'm using Linux. Is there perhaps a special function for this?

Thanks! :)

HelloWorld
  • 3,381
  • 5
  • 32
  • 58
  • See the answers to [this similar question](http://stackoverflow.com/questions/1401234/differences-between-using-realloc-vs-free-malloc-functions) – Bert Nov 10 '12 at 20:15
  • 1
    You might also have a look at http://stackoverflow.com/questions/13247526/: you're a special case of that question where `header_size` is 0. – Steve Jessop Nov 10 '12 at 20:21

3 Answers3

2

If you don't care about the content, the standard idiom is to do free followed by malloc. Finding a block is cheaper than copying it, and there is no guarantee that realloc doesn't do some searching of its own.

As always in such situations, if you really care about performance, it is best to benchmark both solutions on the target platform and under realistic workloads, and see which one performs better.

user4815162342
  • 141,790
  • 18
  • 296
  • 355
  • 1
    The only reason I can think of that `realloc` would be a win in this case is cache warmth (which on modern systems is useful even if you only plan to write on the memory). – Ben Jackson Nov 10 '12 at 21:17
  • @Ben: and if cache warmth is such a huge honking deal on any given platform, you'd hope that the memory allocator would return the most recently freed block where possible. So free-then-malloc would return the same block under roughly the same conditions realloc does, although it might have to do a bit more thinking to reach that decision. – Steve Jessop Nov 10 '12 at 23:21
  • @SteveJessop I was thinking the same, but on reflection, I'm not sure if it's reasonable to expect a new allocation to just reuse the most recently freed block if it fits. That would essentially be [first-fit allocation](http://stargazer.bridgeport.edu/sed/projects/cs503/Spring_2001/kode/os/memory.htm#firstfit) which has problems of its own. [Production-strength allocators](http://tinyurl.com/a6tkaoa) typically deploy a hybrid strategy where they might return the first block or search for a better fit, dependending on a variety of factors, such as request size and arena fragmentation. – user4815162342 Nov 11 '12 at 08:18
  • 1
    @user4815162342: agreed. We're skipping over a lot of details, for instance I was assuming the new request is for more memory than the allocated size of the block just freed, but less than the underlying size of the block just freed (i.e. the case where the caller has to reallocate, but `realloc` could just return the same address). Then I think it's probably a reasonable strategy for the allocator to use that block. If the new request were for a smaller size then yes, it would have to consider other things. – Steve Jessop Nov 12 '12 at 08:28
1

realloc = Alloc then copy and then free the other solution is alloc and free only surely is faster

Ibrahim
  • 342
  • 4
  • 14
0

I would go ahead and trust the realloc implementation to do the right thing. Also in the future you should not be worrying about whether or not the memory is moved ,realloced, etc. this sort of preemptive optimization is unneeded as most of the time spent will be in the context switch from user space to kernel space.

enjoylife
  • 3,801
  • 1
  • 24
  • 33
  • If I free() and then malloc() -- do I switch from the user space to the kernel space 2 times? Or does the compiler perform some sort of optimization here? – HelloWorld Nov 10 '12 at 20:21
  • I'm not to sure a compiler would optimize away two separate fuction calls like that. However the realloc implementation would almost certainly have logic that handles your scenario efficiently. – enjoylife Nov 10 '12 at 20:25
  • But the thing is, the right thing for realloc is not the right thing for OP. The OP doesn't care about the contents of the memory, and realloc is designed to carefully preserve the contents. Trusting the allocator to do the right thing in this case means calling free and malloc. – user4815162342 Nov 10 '12 at 20:49
  • Normally there is **no** syscall when calling `free`. When calling `malloc` there are two cases where a syscall is made: the heap the library handles is too small and the lib asks for more with a `sbrk` call or the allocation is huge to begin with, then the lib will invoke directly a `memmap`. In most cases a `malloc´ will not be a syscall. – Patrick Schlüter Nov 11 '12 at 08:58