Question

I am working on a Windows C project which is string-intensive: I need to convert a marked up string from one form to another. The basic flow is something like:

DWORD convert(char *point, DWORD extent)
{
   char *point_end = point + extent;
   char *result = memory_alloc(1);
   char *p_result = result;

   while (point < point_end)
   {
      switch (*point)
      {
        case FOO:
          result_extent = p_result - result;
          result = memory_realloc(12);
          result += result_extent;
          *p_result++ = '\n';
          *p_result++ = '\t';
          memcpy(result, point, 10);
          point += 10;
          result += 10;
          break;
        case BAR:
          result_extent = p_result - result;
          result = memory_realloc(1);
          result += result_extent;
          *result++ = *point++;
          break;          
        default:
          point++;
          break;
      }
   }

   // assume point is big enough to take anything I would copy to it
   memcpy(point, result, result_extent);

   return result_extent;
}

memory_alloc() and memory_realloc() are fake functions to highlight the purpose of my question. I do not know beforehand how big the result ‘string’ will be (technically, it’s not a C-style/null-terminate string I’m working with, just a pointer to a memory address and a length/extent), so I’ll need to dynamically size the result string (it might be bigger than the input, or smaller).

In my initial pass, I used malloc() to create room for the first byte/bytes and then subsequently realloc() whenever I needed to append another byte/handful of bytes…it works, but it feels like this approach will needlessly hammer away at the OS and likely result in shifting bytes around in memory over and over.

So I made a second pass, which determines how long the result_string will be after an individual unit of the transformation (illustrated above with the FOO and BAR cases) and picks a ‘preferred allocation size’, e.g. 256 bytes. For example, if result_extent is 250 bytes and I’m in the FOO case, I know I need to grow the memory 12 bytes (newline, tab and 10 bytes from the input string) — rather than reallocating 260 bytes of memory, I’d reach for 512 bytes, hedging my bet that I’m likely going to continue to add more data (and thus I can save myself a few calls into realloc).

On to my question: is this latter thinking sound or is it premature optimization that the compiler/OS is probably already taking care of for me? Other than not wasting memory space, is there an advantage to reallocating memory by a couple bytes, as needed?

I have some rough ideas of what I might expect during a single conversion instance, e.g. a worse case scenario might be a 2MB input string with a couple hundred bytes of markup that will result in 50-100 bytes of data to be added to the result string, per markup instance (so, say 200 reallocs stretching the string by 50-100 bytes with another 100 reallocations caused by simply copying data from the input string into the result string, aside from the markup).

Any thoughts on the subject would be appreciated. thanks

Answer 1

As you might know, realloc can move your data at each call. This results in an additional copy. In cases like this, I think it is much better to allocate a large buffer that will most probably be sufficient for the operation (an upper bound). In the end, you can allocate the exact amount for the result and do a final copy/free. This is better and is not premature optimization at all. IMO using realloc might be considered premature optimization in this case.