[acconsta]

For large allocations, realloc can remap virtual memory instead of doing a naive copy:

http://blog.httrack.com/blog/2014/04/05/a-story-of-realloc-a...

[acqq]

That's exactly when I'd use realloc.

Looking who wrote the text, I also respect cperciva and believe he must have some good reasons and I'd be glad read which use cases he had, more than just "what's wrong with different reallocs." Because I'm not surprised that the corner cases aren't to everybody's (or even anybody's) satisfaction. It's C. Less is more and all that.

[cperciva]

And for small allocations, realloc can expand or shrink an allocation in-place, because it knows where it is placing other memory allocations.

[acqq]

Yes. If the allocation block is 16 bytes for example, the string growing from 10 to 11, 12, 13 etc could still be on the same place.

But in which use cases are frequent reallocs actually needed, so much that you can recognize the performance impact? I'd really like to know, as I personally never had such problems. When the single allocations were too expensive I've just used some kind of memory pool. For small stuff realloc is still more expensive than just a few instructions on average when some pool is used.

[cperciva]

The classic example of frequent reallocs is this perl code:

    $x .= $_ while (<>);

I believe this has been fixed now, but perl used to realloc for each append operation, which resulted in O(N^2) time complexity if realloc didn't operate in-place.

[acqq]

But I wouldn't expect of you to assume that a "every time realloc" should be an optimal and at the same time a portable solution in such a case?

[cperciva]

No, I don't. If you look at the code in question, every time I expand an allocation I at least double it.

[acqq]

I'd expect that such growth seldom allows the realloc to remain in-place (unless it's the last thing allocated before and already in a big preallocated chunk of the allocator)? Have you observed what you then get in your program? Which allocator is used underneath?