Delphi 2009 – A Heads-Up for Low-Level Coders

[Estimated Reading Time: 8 minutes]

Prompted by a conversation with some colleagues where-in we collectively speculated about the implementation details of a generic class and what impact – if any – this might have on performance vs a “traditional” polymorphic equivalent, I threw together a quick performance test case in my Smoketest framework, and as a result discovered a couple of significant changes in Delphi 2009 that created some unexpected problems.

1. FastStrings

As I feared, the immensely useful FastStrings library is broken by the switch to Unicode.  Bye-bye FastCharPos, FastReplace etc etc.

This is going to be a major headache for me in my day-job as I work on a 2 million line code base that makes extensive use of FastStrings; string performance is critical to the overall performance of the application as a whole (just one reason we are somewhat wary about the universal nature of the Unicode change in Delphi 2009).

In the lead up to the Delphi 2009 release I repeatedly asked for some indication of what impact the Unicode transition would have on FastStrings and none was ever forthcoming.

I guess I have my answer now.

As I understand it, work on the library stopped some time ago.  I will need to try to get in touch with Peter Morris to see if he has any plans at all to return to it and update it for Delphi 2009 or if he is aware of anyone that is.

I don’t know at this stage what – if anything – can be done to make FastStrings usable with Delphi 2009, other than changing the declarations in the library to AnsiString so that the compiler won’t let you call them with UnicodeString (currently they are declared as just String, which of course now is UnicodeString).

I’ve done some initial testing of string performance in Delphi 2009 and have actually been pleasantly surprised so far.  Simple string concatenation of UnicodeString seems for some reason to be actually faster than ANSIStrings, and faster even than ANSIString handling in Delphi 7 (with FastMM).

I find this puzzling given that I was sure I had seen the new TStringBuilder class being recommended for performance reasons.  For simple string concentation at least, the exact opposite appears to be the case.

ANSIString performance on the other hand I think will suffer quite badly in Delphi 2009, most – if not all – of which I think is the result of an assumption of Unicode in the RTL.

There is no ANSIString version of IntToStr() for example – there is only one IntToStr() and it returns String, i.e. a UnicodeString.  This means that use of IntToStr() (or any of a number of common RTL string routines) when working with ANSIString variables will inevitably incurr ANSI/Unicode conversions that previously they did not.

With this assumption propogated throughout the RTL, using ANSIString in a Delphi 2009 application could actually prove costly if string performance is a concern.

I don’t quite understand why CodeGear could not have provided ANSI versions of these RTL routines (IntToStrA, for example) alongside the newly Unicode capable “default” implementations.

2. News FLASH!  The VMT Has Changed

After fixing compilation problems with FastStrings (i.e. removing FastStrings from the code!) upon attempting to run my performance test case I immediately ran into an access violation in the code that identifies the published methods in my test case classes.

The reason appears to be that the layout of the VMT (Virtual Method Table) has changed.

The help files proved to be rather begrudging in giving up their secrets in this area.  The Class Types topic itself that describes the VMT layout clearly has not been updated (and took some finding, being now a section buried in an Internal Data Formats topic) as it still describes the previous VMT layout.

Ironically the deprecated vmtXXX constants do seem to have been updated – these deprecated constants seem to include some all new, instantly deprecated ones.

So for example I can see that vmtEquals (a new entry at -44) occupies the position in the VMT that previously contained a pointer to the class name, and the entry that used to contain the instance size is now occupied by a pointer to the GetHashCode method (vmtGetHashCode).

As far as I can tell from the various new vmtXXX constants the changes are three additional method pointers inserted between the vmtParent and vmtSafecallException entries:

    Equals            : Pointer;                // -44
    GetHashCode       : Pointer;                // -40
    ToString          : Pointer;                // -36

So all offsets previously at -36 and above (below?) are affected.  There are also some new initial entries in the “user” virtual methods area, i.e. at positive offsets:

    QueryInterface    : Pointer;                // 0
    AddRef            : Pointer;                // +4
    Release           : Pointer;                // +8
    CreateObject      : Pointer;                // +12

Now obviously the VMT is an internal implementation detail of Delphi, and everyone knows that relying on it’s layout is dangerous – I even have a warning to myself to this effect in my own code!

So don’t mistake this for a complaint at the layout having changed – it’s just a heads-up to anyone who themselves may have used the previous documentation and/or other works describing the previous VMT layout (which up to now has proven remarkably stable) and a caution that the Delphi 2009 documentation itself does not appear to have been completely updated.

For my own routines using the VMT, that wasn’t the end of the story….

3. PointerMath

Delphi 2009 now supports pointer math on all pointer types! YAY!  🙂

Seriously – this is HUGE!

Previously pointer math was only supported on PChar pointers. You could of course Inc() any typed pointer by the size of the type pointed to, but actual addition of an arbitrary offset (among other things) simply wasn’t allowed.  So to increment a pointer you would have to write something like, e.g:

  ptr := Pointer(Cardinal(ptr) + offset);

Which is cumbersome to say the least. So instead I was naively exploiting the fact that PChar was a pointer to a single byte-size data type:

  Inc(PChar(ptr), offset);

Can you see the problem?

PChar in Delphi 2009 is no longer a pointer to a single byte-sized Char, it’s a pointer to a WideChar, which of course is TWO bytes. Oops.

“Aha!” I thought “Pointer math to the rescue?”

The new pointer math capability is subject to a compiler switch (is OFF by default) so I could now write:

  {$pointermath ON}
  ptr := ptr + offset;
  {$pointermath OFF}

But there are two problems with this.

First, if ptr is a typed pointer then the resulting increment of ptr is offset * type size. In other words, this is exactly equivalent to a call that you could previously have made using Inc().  This is perhaps to be expected, but it might catch you out – as it initially did me.

The second problem is this of course won’t compile in older versions of Delphi; wrapping all the necessary conditionals and compiler options to enable compatibility with those older compilers whilst preserving the state of the switch in any current project quickly gets out of hand, and in any case I will still need old-style pointer adjustment code for those older compilers.

So in the end I just changed my PChar to a PByte and all was again right with the world.

  Inc(PByte(ptr), offset);

Just another example of “say what you mean if you really mean it”.

In this case, I want to increment in byte-size chunks, so use a PByte already!  Not some other pointer that happened – at the time – to also point to a one-byte size data type.

Pointer math is undeniably a useful addition to the language, but when it comes to advancing typed pointers I’d suggest sticking to Inc() calls – it’s portable between Delphi versions, is directly equivalent to the new alternative, but will be more familiar to the widest audience since the Inc() behaviour is more likely to be already understood where plain addition of ordinal values to pointer types is new and therefore not so familiar.

It’s also far cleaner to coerce byte offsets from an Inc() call (where required) than it is using pointer math:

  Inc(PByte(ptr), offset);

vs

  ptr := PValueType(PByte(ptr) + offset);

4. The Frustation of the New

Pointer Math does again highlight an inevitable frustration with new language features.

Apart from the simple job of learning how the new features behave in code, the ability to use them in code destined (or at least intended) to be shared with the wider Delphi community is severely limited by the uptake of the latest version of Delphi.  At the very least it means having to wait some time before incorporating them in code until the latest version has gained traction in the community, and even then you either have to duplicate code subject to compilation directives or close the door on users of older versions of Delphi.

This has always been, and will always be, a problem.  There is no easy answer.

But in the case of Delphi 2009 that problem is exacerbated in my view by the fact that Unicode is so tightly coupled to Delphi 2009.  The likelihood that Delphi 2009 will become the ubiquitous Delphi version any time soon is – imho – going to be limited by the fact that anyone wishing or needing to maintain ANSI applications are likely to be running Delphi 2009 alongside their older Delphi compilers.

5. Generics are FAST!

I eventually fixed my problems and got my performance test case running.

It was not an exhaustive test, I simply drafted two routines that added the integers 1 thru 1000 to an integer list and then iterates over the list, summing the items in the list.

Two different integer list classes were used and the performance of the code in each case compared (for brevity a lot of implementation code is not shown):

    TGenericIntegerList = Generics.Collections.TList;

    TDerivedIntegerList = class(Classes.TList)
    private
      function get_Item(const aIndex: Integer): Integer;
    public
      procedure Add(const aInteger: Integer);
      property Items[const aIndex: Integer]: Integer read get_Item; default;
    end;

    TTestGenerics = class(TPerformanceCase)
      procedure GenericList;
      procedure DerivedList;
      procedure EnumGenericList;
      procedure EnumDerivedList;
    end;

begin
  TestSuite.Initialize;
  TTestGenerics.Create(2, pmSeconds);
  TestSuite.Ready;
end.

The test case is configured to run repeatedly for 2 seconds – Smoketest then reports the number of complete executions of each method in that period.

Each of the test case methods follows the same basic pattern. The GenericList method is shown here:

var
  i: Integer;
  r: Integer;
  list: TGenericIntegerList;
begin
  r := 0;

  list := TGenericIntegerList.Create;
  try
    list.Capacity := 1000;

    for i := 1 to 1000 do
      list.Add(i);

    for i := 0 to Pred(list.Count) do
      r := r + list.Items[i];
  finally
    list.Free;
  end;

The EnumGenericList method replaced the explicit iteration of the list with an enumerator based version, i.e:

    for i in list do
      r := r + i;

This had nothing to do with the performance of generics as such but was more out of curiosity, as I had a suspicion that I would see a difference.  The enumerator test for the derived list implementation was implemented for completeness, but frankly you wouldn’t enumerate over such an implementation since – out of the box at least – the enumerator for that class yields Pointers, not Integer, so some real nasty type-casting is needed.

The results were good news for generics, not so good for enumerators.

The generics based implementation of a TList, in this performance test case, was consistently at least 50% faster than the implementation derived from a regular TList.

A 50% improvement is something absolutely not to be sniffed at.

Unfortunately the enumerator implementations aren’t quite so rewarding. Admittedly the test cases don’t completely isolate the list iteration code for a true test of manual iterations vs enumerators, but nevertheless, in this case the enumerator based test methods were at least 25% slower than their manual iteration counterparts.

For completeness I should mention that the performance impact of an enumerator was actually slightly worse for the derived class implementation.

On the face of it, this would seem to confirm something that I have always suspected with enumerators – the syntactic sugar they provide comes at a not insignificant performance cost and I’ve personally never considered the syntactic sugar as earth-shatteringly significant as some.

It should be said that in a very large proportion of applications the performance impact is likely to be insignificant, but it is something that developers should perhaps be aware of when working in performance critical areas.

At the same time, it does seem that generics deliver more than just syntactic sugar.  I am frankly stunned by the performance improvement that they seem to bring.

It makes it even more of a shame that the implementation in Delphi 2009, as it stands currently, lacks operator constraints.  This demands a great deal of hoop jumping and circumlocutory tricks to create generic classes that are anything more than simple containers.

This problem is not confined to Delphi though – .NET and C# generics have similar problems.

Hopefully these shortcomings will be addressed in the future (and perhaps an opportunity for Delphi to steal a march on C#).  But for now, the prospect of containers that are not only type-safe but also more efficient is enough to get me a lot more excited about generics than I – for one – previously was.