I'm writing an application that generates a bunch of n strings (bit)length l and then does a comparison between all possible pairs.
I first allocate memory for n strings of length l
char* pStr = (char*)(malloc(n * l));
Then I run my comparison of the last char of the last string with the last char of all other strings and store my results. After this I technically do not need to store that char anymore so I could use pStr = realloc(pStr, n*l - sizeof(char*)) to free up that memory.
Im wondering if this makes sense to do, say for every char, or for every string after the whole string has been compared. If you increase size of the pointer and realloc can't do so contiguously it will copy the memory to a new location instead which isn't very efficient. Could something like this ever happen when shrinking the allocated memory or not since it can always be contiguous?
Also am I assuming correctly that the memory freed when resizing using realloc is the last char in the pointer? If so would there be any way to instead remove the first char and shift the remaining ones to the pointer address?
Unless you are allocating memory in-between the reallocations, there is no chance that you will run out of memory, so do not need to be reallocating anything.
If you are running out of memory, then freeing up tiny chunks is probably not going to save you.
Reallocations to a smaller size will typically happen in-place, although no guarantees are given about that. (And yes, you are assuming correctly, that it is always the end of the block that gets chopped off.)
When you reallocate a block to a smaller size, what typically happens under the hood is that the standard library first sees if it can create a new free block right after the end of the newly reallocated block to hold the freed up memory. Every free block begins with a header, which typically contains two pointers (doubly-linked free list) and one length; this is a whole 4 + 4 + 4 = 12 bytes on a 32-bit system, double that on a 64-bit system.
If the number of bytes you are releasing is smaller than that, then the standard library cannot create a new free block, so one of the following two things will happen:
Generally, dynamic memory allocation (and reallocation, and freeing,) is expensive, so the fewer of it you do, the better.
For C++ applications that do a lot of dynamic memory allocation, one of the biggest problems is memory fragmentation, and the more you churn the memory around, the more fragmentation you will have.
So, bottom line is:
For a vaguely defined situation such as this, there is no definitive answer, but the reallocations you are contemplating are not likely to be efficient. As a matter of fact, most chances are that they are going to be very inefficient.
P.S.
If you are an application programmer, and you find yourself thinking of saving memory of the order of bytes here and there, or saving processing time of the order of clock cycles here and there, the savings are never worth the mental effort.