All Things Seen and Unseen » Delphi

Objects on the Stack: A Delphi Relic

Rob — Sun, 28 Aug 2005 15:43:10 +0000

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.

Download StackObjects for Delphi (6K)

Post from: All Things Seen and Unseen

Objects on the Stack: A Delphi Relic

Readers who viewed this page, also viewed:

Similar Posts:

QDB: Quick Database Components

Rob — Mon, 18 Jun 2001 15:46:52 +0000

Borland’s Delphi© makes the construction of Windows applications easier than ever. In particular, the Borland Database Engine (BDE) offers enormous power with great ease. Sometimes, however, the full might of the BDE is overkill. Wouldn’t it be better for your simple projects to use a simple tool, one that could be distributed inside your EXE and didn’t require enormous DLLs to function?
The QDB components for Delphi offer fast, indexed access to a flat-file database of variable-sized items. QDB is quick, easy to use, and comes with full installable help. It’s also free! Caveat! It is some years since these components were developed and they probably won’t function beyond D5 without a lot of tweaking. They are–regrettably–also unsupported. Nevertheless I hope you find them useful in some way.
Also available are the usual demonstration applications written to show the power and ease of QDB. There is a simple address book, a rewrite of Borland’s Animals demo, and a rudimentary knowledge-base system. They each come with full source code.

Post from: All Things Seen and Unseen

QDB: Quick Database Components

Readers who viewed this page, also viewed:

Similar Posts:

Snoop: Memory Leak Sniffer

Rob — Mon, 18 Jun 2001 15:41:43 +0000

Writing programs that work at all is difficult enough without having to track down memory leaks and strange problems with overwritten memory. Snoop and Snoop Monitor make it easy to snoop out those bugs — and they’re free. Caveat! It is some years since these components were developed and they won’t function beyond D5. They are–regrettably–also unsupported. Nevertheless I hope you find them useful in some way.

Snoop v2.0 has been completely rewritten and has a bunch of new features. It works correctly with DLL files and with multi-threaded programs and now comes with a Delphi expert to display its memory-leak reports and jump to the offending line in your source code.

Post from: All Things Seen and Unseen

Snoop: Memory Leak Sniffer

Readers who viewed this page, also viewed:

Similar Posts:

CompDocs: Structured Storage Wrapper

Rob — Mon, 18 Jun 2001 15:39:25 +0000

OLE Structured Storage (or Compound Documents or DocFiles … the names change regularly!) provide a clever way to have a whole file-system within a single file with nested ‘directories’ (storages) and ‘files’ (streams). There’s also the ability to do transaction processing: keeping modifications in limbo until ‘committed’ or rolled-back. The only catch has been that the necessary APIs are complex, most un-Delphi-like, and in places self-contradictory. Indeed, the DCU supplied with Delphi 1 is error-ridden. There’s also the matter of the small print and the arcane error codes! With these complexities it’s no wonder that most Delphi developers have avoided Compound Documents.
The CompDocs components available here encapsulate OLE structured storage in a straightforward and Delphi-like way. They protect you from most of the hidden problems with using the API directly and work with all versions of Delphi. As usual these components are available for free. Caveat! It is some years since these components were developed and they probably won’t function beyond D5 without a lot of tweaking. They are–regrettably–also unsupported. Nevertheless I hope you find them useful in some way.

TRootStorage models a physical file on disk while TStorage and TStorageStream model substorages and streams. Storages can be nested and can be opened in transacted mode. Creating temporary storages and streams is made easy. The TStorageStream is fully compatible with other Delphi stream types.
I have provided a simple example program, Viewer, which browses the contents of a compound file, showing the names of storages and streams. You’ll be surprised to discover the complexity of many files.

Compound Documents for Delphi (37K)

Post from: All Things Seen and Unseen

CompDocs: Structured Storage Wrapper

Readers who viewed this page, also viewed:

Similar Posts:

Widgets: Title-Bar Buttons

Rob — Mon, 18 Jun 2001 15:37:32 +0000

Another title-bar button? Yes, but one that works simply and cleanly to provide buttons which mimic the look and feel of Windows’ own frame controls by using Windows’ own drawing technique.
Each Widget contains a single glyph from a truetype font. Windows uses the “Marlett” font for its own glyphs but you can use any and choose a colour and weight too. Widgets have their own Hint property and are even visible at design-time. A component editor is included to make Widgets very easy to use. Caveat! It is some years since these components were developed and they probably won’t function beyond D5 without a lot of tweaking. They are–regrettably–also unsupported. Nevertheless I hope you find them useful in some way.

Widgets for Delphi 2, 3 & 4 (13K)

Post from: All Things Seen and Unseen

Widgets: Title-Bar Buttons

Readers who viewed this page, also viewed:

Similar Posts:

Maps: Generic Associative Containers

Rob — Mon, 18 Jun 2001 15:33:27 +0000

The Maps Library offers nine genuine generic container classes. Just as TStringList lets you keep lists of objects indexed by a string value, Maps let you keep lists of just about any type, object or atomic, indexed by whatever type you like.
The nine different kinds of map have different performance characteristics allowing you to choose the perfect container for your application, whether you need fast insertion, super-fast searching, random-access, or whatever.
The library is quite compact and surprisingly efficient given its generic nature. A simple demo is also available. Caveat! It is some years since these components were developed and they probably won’t function beyond D5 without a lot of tweaking. They are–regrettably–also unsupported. Nevertheless I hope you find them useful in some way.

Maps v.1.11 for Delphi 2, 3, 4 & 5 (66K)

Anagram demo(295K)

Post from: All Things Seen and Unseen

Maps: Generic Associative Containers

Readers who viewed this page, also viewed:

Similar Posts:

FirstAid

Rob — Mon, 18 Jun 2001 07:48:31 +0000

Every so often the Delphi IDE (from D2 until at least D7) seems to get confused about its line numbers: errors are reported in places there is no code; the debugger jumps about with no apparent relation to the code that is being executed. The Delphi newsgroups propose many diagnoses but, in my experience, the culprit has always been code pasted into the IDE from another source. The Delphi IDE flags line breaks with the characters $D$A but some other editors use $A$D or even just $A or $D. The IDE understands such markers enough to format the code correctly but not enough to mark errors properly. The solution is straightforward but awkward: filter out any improper codes. FirstAid does the job for you.

FirstAid for Delphi (124K)

Post from: All Things Seen and Unseen

FirstAid

Readers who viewed this page, also viewed:

Similar Posts: