[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?

[cperciva]

I haven't looked. I use whatever allocator is in libc anyway, so it will depend on what platform you're running on.

At worst, using realloc produces the same results as malloc/memcpy/free. At best, it might save a memcpy. No harm in giving it that flexibility.