Question

In another question, David Heffernan posted a comment about his “all time least favourite Delphi construct”:

SetLength(FItems, Length(FItems)+1);

The construct he dislikes was heavily used in the Pebongo project, such as in this excerpt:

procedure TBSONDocument.ReadStream( F: TStream ); 
var 
  len : integer; 
  elmtype : byte; 
  elmname : string; 
begin 
  Clear; 
  f.Read( len, sizeof( len ) ); 
  f.Read( elmtype, sizeof( byte ) ); 

  while elmtype <> BSON_EOF do // Loop
  begin 
    elmname := _ReadString( f ); 
    SetLength( FItems, length( FItems ) + 1 ); // This, spotted by TOndrej
    case elmtype of 
      BSON_ARRAY: FItems[high( FItems )] := TBSONArrayItem.Create; 
      BSON_BINARY: FItems[high( FItems )] := TBSONBinaryItem.Create; 
      ...
    end; 
    f.Read( elmtype, sizeof( byte ) ); 
  end; 
end; 

What are the alternatives?

Answer 1

What I was talking about was growing dynamic arrays 1 element at a time:

SetLength(FItems, Length(FItems)+1);

In a loop, and with large arrays, this can lead to memory address fragmentation. When this happens you can find yourself unable to allocate a large contiguous block of memory even though the total available address space is large. If you are constrained by 32 bit address space this can be a very real problem. In addition, performance can also be an issue.

There are a variety of ways to avoid the problem:

• Pre-allocate the array. Sometimes this involves iterating twice, once to count the items and once to populate the array. This can be perfectly efficient. In fact, that is precisely what TBSONDocument.Clone in your question does.
• Use a TList or TList<T> container. Although these use dynamic arrays as their underlying storage they implement a capacity based approach to allocation. When they are full, they allocate a large number of extra items in anticipation for future additions. This again can be perfectly efficient.
• Yet another option, to be used as a last resort, is to move away from contiguously allocated memory. Allocate memory in chunks and use an indexed property of a class or record to map between indices and the actual chunk and location where the storage lives. This is particularly effective at avoiding address space fragmentation.