Now here’s a dangerous and dubious technique for you to try at your own risk–
allocate objects on the stack instead of on the heap. Hey, C++ does it all the
time!
The advantage: object allocation is at least twice as fast on the stack.
Disadvantage: only applicable to objects which are local variables.
Example
First, an example and then the explanation.
uses
StackObjects;
procedure Test;
var
t : array [0..199] of TMyObject;
n : Integer;
begin
StackObjects.BeginStackAllocation(200*50, false);
for n := 0 to 199 do
t[n] := TMyObject.Create;
…
StackObjects.EndStackAllocation;
end;
Notice that t is a local variable–an array of objects. To get those objects
allocated on the stack along with the array itself all you need to do is call
BeginStackAllocation before they are created. BeginStackAllocation
reserves a portion of the stack for allocations (I’ll explain the boolean
parameter later). If you don’t reserve enough space an exception will be
raised. You might also have to use the $M compiler directive to make enough
space available. Then you just go ahead and create and use the objects as
you see fit. Finally, after you are through using them you call EndStackAllocation,
after which object allocations revert to the heap as usual.
Notice that there is no need to Free the objects on the stack. They automagically
vanish when they go out of scope. Reference-counted variables (e.g., dynamic
arrays) needs to be treated carefully and explicitly finalized before ending the
stack allocator. You also have to be careful that you don’t (explicitly or implicitly)
create any objects from a superior scope between calls of Begin- and EndStackAllocation
or they will vanish too and explode your app. The VCL user-interface is the
source of potential problems in this regard which the attached demo discusses
ways of getting round.
The stack space set aside by BeginStackAllocation is available wherever it is in
scope. This applies to procedures too. Memory allocated in an inner scope may
be safely used in the original scope. You could, in principle, make your whole
program into a procedure and put all allocations on the stack. I haven’t tried
that yet!
How it Works
Deep in the grids.pas unit the VCL itself uses this technique to allocate memory
on the stack. The trick is to shift the stack pointer to make room for your
extra variables. Such allocations disappear when the current procedure exits.
Grids uses two routines, StackAlloc and StackFree, to achieve some very fast
dynamic memory allocation.
I’ve adapted the method to work with other Delphi objects instead of just plain
vanilla memory and in the process made it a little safer. What the StackObjects
unit does is provide a plug-in Delphi memory manager that uses stack memory.
When BeginStackAllocation is called the new stack memory manager replaces the
standard memory manager and all subsequent memory allocations come from the
reserved space on the stack.
Now re-routing ALL memory allocation to the stack causes a number of problems.
It is amazing how hard it is to keep track of all the string variables that get
allocated behind the scenes and linger to blow up your app. For this reason all
dynamic string allocations are kept from the stack and re-routed to the standard
memory manager. In addition the stack memory manager can either handle all the
remaining allocation (including ordinary memory, and dynamic arrays) or just
the allocation of objects. Remember the boolean parameter in BeginStackAllocation.
If true is passed, only objects are created on the stack. Otherwise New and Dispose,
StrAlloc, StrDispose, GetMem, FreeMem, creation and destruction of dynamic arrays,
etc. all allocate on the stack.
It is essential to call EndStackAllocation before leaving the local scope. It reinstates
the default memory manager. If you don’t you’ll blow things to pieces. You could
use a try … finally block to ensure the memory manager is replaced in the event of
a problem but that might cause some stack-allocated entities to be freed by the
standard manager with more explosions!
The commented code in StackObjects.pas and the demo should explain the details.
Dangers
Make sure you match BeginStackAllocation and EndStackAllocation
Beware of implicit creation of objects from a superior scope
Don’t try and use with multiple threads.
Don’t try and use with other memory managers–at least not while stack allocation
is in progress.
This is an edgy technique, subverting Delphi to squeeze out some extra speed.
If I haven’t already made myself clear on this point … don’t blame me if,
in trying this code, you destroy your computer or start World War III.