The tradeoff, though, seems to have been compiler stability.  Trying to do anything with Generics in D2009 before Update 3 came out was a nightmare, and even after, (and even in D2010,) there were still plenty of dark corners where you can end up with an Internal Compiler Error or linker error on something that, syntactically speaking at least, is perfectly cromulent Object Pascal.

I think I ran into the darkest corner of all this morning, or at least the darkest one that’s been found yet.  I found something that not only won’t compile, but will either destabilize or completely crash the IDE if you try to compile it.

I was trying to build a specialized tree class.  Trees are pretty familiar to anyone who’s taken a Data Structures class:  Each TreeNode contains a Value and pointers to two or more other TreeNodes.  There’s an excellent implementation of the standard binary tree concept in DeHL, for example.  This works really well if you’re trying to build a standard binary tree, but when you want a hierarchical tree, (like the way the VCL’s TTreeView organizes information,) the standard binary tree concept doesn’t work so well.

I came across a situation while building the TURBU editor where I had a list of objects with an ID property and a Parent property, where both are integers, and I needed to come up with a list of all objects whose Parent value was equal to the ID value of a given object.  In other words, all immediate children of a certain node.

Obtaining all descendants of a binary tree node is trivial if you understand recursion.  But that’s not what I needed; I needed all immediate children, but not their children.  So a different kind of tree is needed, one composed of TLists of nodes instead of binary subtrees of nodes.  So that’s what I wrote.  Each node contains a value, a pointer to the list it’s in, and a pointer to the list containing its children, and each list is a list of nodes, plus a pointer to its parent node.  It ended up looking like this:

unit hierarchy_tree;

interface
uses
   SysUtils, generics.collections;

type
   THierarchyTreeList<T: class> = class;

   THierarchyTreeNode<T: class> = class
   private type

      TEnumerator = class(TEnumerator<T>)
      private
         FTopNode: THierarchyTreeNode<T>;
         FIndex: integer;
         FNext: TEnumerator;
         FTopRead: boolean;
      protected
         function DoGetCurrent: T; override;
         function DoMoveNext: Boolean; override;
      public
         constructor Create(value: THierarchyTreeNode<T>);
         function GetCurrent: T;
         function MoveNext: boolean;
         property Current: T read GetCurrent;
      end;

      TNodeList = THierarchyTreeList<THierarchyTreeNode<T>>;

   private
      FData: T;
      FRight: TNodeList;
      FList: TNodeList;
      function GetParent: THierarchyTreeNode<T>;
      function GetLevel: integer;
   public
      constructor Create(value: T);
      destructor Destroy; override;
      procedure Add(node: THierarchyTreeNode<T>); overload;
      procedure Add(value: T); overload;
      function GetEnumerator: TEnumerator;

      property List: TNodeList read FList;
      property Right: TNodeList read FRight;
      property Parent: THierarchyTreeNode<T> read GetParent;
      property Level: integer read GetLevel;
      property Data: T read FData write FData;
   end;

   THierarchyTreeList<T: class> = class(TObjectList<THierarchyTreeNode<T>>)
   private
      FParent: THierarchyTreeNode<T>;
      FLevel: integer;
      procedure SetParent(Value: THierarchyTreeNode<T>);
   public
      constructor Create(parent: THierarchyTreeNode<T>);
      function Add(value: THierarchyTreeNode<T>): integer;
      property Parent: THierarchyTreeNode<T> read FParent write SetParent;
      property Level: integer read FLevel;
   end;

implementation

{ No implementation provided.  Compiler will break before reaching this
point anyway. }

end.

You can try to compile this if you want, but make sure to save any work before you try.  Turns out this will break the compiler.  The compiler will try to process this, get stuck for about 30 seconds, all the while sucking up memory like there’s no tomorrow, until it hits 1.5 GB according to Task Manager, and then break.  It may crash, or it may simply become unstable.  If you’re really lucky, you’ll get an Out Of Memory error so at least you have some idea what’s going on.

After sharing this problem with a few other coders, I’ve got some idea what’s going on.  The node uses the list in its definition, and the uses the node as its generic parameter.  Apparently the compiler is trying to resolve one of these generics immediately, instead of waiting for instantiaion when a value of T can be provided, and getting stuck in an infinite loop, even though the definition is not infinitely recursive.

I’ve submitted a bug report about this to QC . Thanks to Moritz Beutel and Stephen Kamradt for the insights as to what was going on!

1. As a list of strings, either a simple string list or occasionally as a quick-and-dirty parser by setting the DelimitedText or CommaText properties in order to create a list of strings.
2. As a string-string key-value pair dictionary, using the .Value property.
3. As a string-object key-value pair dictionary, using the .Objects property.

You don’t often see the same TStringList use functionality from more than one of the above three modes.  So that makes me wonder, now that we have proper key-value pair dictionaries in the RTL, with better APIs for storing key-value pairs and especially for retrieving the value associated with a certain key than what TStrings provides, what would TStringList be like if Generics.Collections.pas had been available in Delphi 1?

I think there would probably be two predefined classes:

• TStringList = class(TList<string>);  It would implement CommaText and DelimitedText, and the LoadFromX and SaveToX methods.
• TStringDictionary = class(TDictionary<string, string>); It would implement LoadFromX and SaveToX,

No predefined string/object dictionary, since they’re easy enough to create yourself and get the right class for the objects.  It seems to me that that would be a more logical design.  But then again, how would that affect the way a bunch of VCL collection controls use custom TStrings descendants as string/object dictionaries?  (TListBox comes to mind.)

It’s an interesting question.  How would having generics available from Delphi 1 have affected the design of TStrings and the VCL in general?  Any thoughts?

P.S. Happy 15th birthday, Delphi!

Disclaimer: Even when I give the story from his perspective, they aren’t exact quotes by any means. My memory’s real good, but not that good! But this is the basic idea of what he said, with no ficionalizing.

He wasn’t originally a computer programmer. Hadn’t even really studied it in college. David’s degree was in accounting, and he was working as an accountant with an insurance company back in the 90s. He explained, “They had a tuition reimbursement program set up with the local college. You could take classes there, and as long as you got a B or better at the end of the semester, they’d pay you back for the courses. The tuition was several hundred dollars per course, so you had a pretty strong incentive to do well in them!

“Anyway, I was working with this insurance company, and my job was to take care of custom policies. They had this thing where they’d write out custom policies for all the small businesses in the area, which were all more or less from the same template but with a bunch of cudtomized details tailored to each one. And every month I’d get this big stack of a few hundred sheets of printer paper and have to crunch all the numbers. It was annoying, really tedious work.” We commiserated with him about how much that must have sucked, as we sat there waiting for our orders to arrive.

“After a while I got them to give me direct access to the database to read these values from, instead of giving me a printout from it, and that helped a bit, but there was still a lot of stuff I had to do by hand. I got to thinking that this was the sort of thing that could be simplified by writing a computer program, if only I knew how to. Well, they had a course at the college on database programming, and I signed up for it.”

He looked at us a bit wryly and said, “To this day I don’t know how I actually got into the class. I wasn’t paying enough attention when I registered for it. Turns out it was a graduate-level Computer Science course! I didn’t have any CS background, and after the first day in the class I was completely lost. The entire grade for the semester was based on a project. You needed to create a database program to solve a real-world problem. And it had to have a graphical user interface, it had to have reporting…” he listed off several requirements, and this was about where I saw where the story was headed. It was almost like he was reading off a lit of Delphi’s historical strong points.

“I was completely lost. I didn’t even know where to start! But I’d already paid the tuition and I couldn’t get it back without a B or better in the class. So I went to talk to a friend of mine who was a professor in the CS department. I explained the problem to him, and he listened, and when I was done he thought about it for a moment. ‘Well,’ he said, ‘you could try Visual Basic, but there’s this new thing that just came out that might work better for you. It’s called Delphi.’ He was able to get me set up with a copy, and I installed it on my computer at work.

“For the next few months, that’s pretty much what my life was about. I’d work on my job during the day, then stay after in the evening to figure out how to use Delphi and how to make it talk to a database. Needless to say, I didn’t get very much sleep! But when the end of the semester rolled around, I had a working program. And I ended up getting an A on the class.”

Ladies and gentlemen, that right there is a testament to the power of the Delphi language! From a cold start, no programming background at all, to writing an app good enough to ace a graduate-level CS course in a matter of months. Granted, David’s a very intelligent guy, and that certainly played a part in being able to pick it up so quickly, but even so, a lot of it’s the Delphi language itself. (You’d never see results like that in the C family!)

Delphi is an evolution of Pascal, which was originally created by Niklaus Wirth as a teaching language. Being easy to learn was an explicit design goal. That originally came with a few tradeoffs and drawbacks, but the Borland team managed to extend the language into a powerful general-purpose programming system while still holding to the Pascal philosophy of making the language’s syntax and semantics as intuitive and easy to understand as they could. That’s what made it possible for David to pick up so quickly, and that’s why even experienced programmers who have been coding for years love Delphi: the language just makes sense. It may not have <insert trendy feature from some other language here>, but language design makes the code, even code the dreaded “other people’s” variety, easier to read and comprehend, and that counts for a lot in modern team-based software development.

In Object Pascal, things make sense, and they tend to work right even if you don’t quite understand them. IMO this is the main reason why so many people who know Delphi actually find it enjoyable to work with, as opposed to just something they write code in because they need to get something written, and why they sometimes even go so far as to call it “the best programming language.”

For example, let’s take the common case of trying to create a custom control that’s mostly like an existing VCL control, but slightly different.  You need to change some minor feature in some way.  Unfortunately, that feature relies on a private field in the base class that the author didn’t have the foresight to make Protected, and so to make it work, you end up having to copy and paste half the original class into your descendant.  I’ve seen a few examples of “custom components” incorporate pretty much the entire base class, because they had to in order to make one change.  With RTTI generated for private fields in Delphi 2010, we can remedy this oversight, to a certain degree at least.

One thing that’s always bugged me is the behavior of TDBComboBox.  It’s not all that often that you have a list of strings that you want to be able to choose from to put into a TStringField.  More common, in my experience at least, is to want to use it like a radio group:  fill it with strings and let the “important” property be ItemIndex, not Text.  (Though, now that I look at it, TDBRadioGroup does the same thing: it acts like what you care about is the name of the radio button, not its ItemIndex.)  So far, the only way to use data-aware controls to represent an enumerated type or similar selection by index of a group of strings is to set up a second dataset and use a lookup combo box.  I dunno about you, but that always felt like a hack to me. I asked on StackOverflow, more than a year ago, if there was a control that would do what I’m looking for, and never got a good answer, so I decided to try and build my own.  Let’s see how we can do this, and how using extended RTTI makes the fix easier.

We start by creating a descendant of TDBComboBox.  I’ll call it TDBIndexComboBox.  TDBComboBox already does almost everything we need.  All that’s really significant is the ItemIndex requirement.  We want the data-aware property of the control to be “aware of” the ItemIndex property instead of the Text property.  So first we need to know how it handles data-awareness.  Let’s look at the constructor for our first clue:

//inside the constructor
  FDataLink := TFieldDataLink.Create;
  FDataLink.Control := Self;
  FDataLink.OnDataChange := DataChange;
  FDataLink.OnUpdateData := UpdateData;
  FDataLink.OnEditingChange := EditingChange;

It uses a TFieldDataLink object, declared in DBCtrls.pas, and assigns some TDBComboBox methods as event handlers.  If we want to change the way the data-aware control works, we’re going to have to override those event handlers in our descendant class.  Problem is, the FDataLink field is private, and there’s no way to get at it.  TDBRadioGroup and TDBLookupControl offer a protected “property DataLink: TFieldDataLink read FDataLink;”, but the rest of them don’t, for whatever reason.  So our first task is getting at FDataLink.

T0 use extended RTTI, you need a TRttiContext.  It’s an interface to a global RTTI object pool, and you only need one of them. So it makes sense to attach it at the class level instead of to each individual object.  So as long as we’re doing this the Delphi 2010 way, let’s put it in a class constructor.

type
   TDBIndexComboBox = class(TDBComboBox)
   private
      class var
         FContext: TRttiContext;
         FDatalinkField: TRttiField;
      class constructor Create;
      class destructor Destroy;
...

class constructor TDBIndexComboBox.Create;
var
   classType: TRttiType;
begin
  FContext := TRttiContext.Create;
  classType := FContext.GetType(ClassParent.ClassInfo);
  assert(assigned(classType));
  FDatalinkField := classType.GetField('FDataLink');
  assert(assigned(FDatalinkField));
end;

class destructor TDBIndexComboBox.Destroy;
begin
   FContext.Free;
end;

This is pretty straightforward.  Create the RTTI Context, retrieve the RTTI info for the parent class, where FDatalink is declared as a private field and retrieve an RTTI reference to FDatalink.  I threw in a  few assertions for safety checks.  If we happen to be running on a codebase where extended RTTI for private fields has been turned off somehow, this will cause hard-to-track-down access violations when we try to use the component.

Next, we need to actually use the datalink, now that we have an RTTI reference to it.  So let’s define the constructor.

//Class definition, continued from above
   private
      FDataLink: TFieldDataLink;

      procedure SetComboText(const Value: string);
      function GetComboText: string;
      procedure UpdateData(Sender: TObject);
      procedure DataChange(Sender: TObject);
   protected
      property DataLink: TFieldDataLink read FDataLink;
   public
      constructor Create(AOwner: TComponent); override;
   published
      property Style default csDropDownList;
   end;

...

constructor TDBIndexComboBox.Create(AOwner: TComponent);
begin
  inherited Create(AOwner);

  FDataLink := FDatalinkField.GetValue(self).AsObject as TFieldDataLink;
  FDataLink.OnDataChange := DataChange;
  FDataLink.OnUpdateData := UpdateData;
  self.Style := csDropDownList;
end;

I could have used the datalink field object directly throughout the component, but since I need it in more than one method, I decided to redeclare it as a field for simplicity’s sake, and make a protected property for it so it can be extended easily in the future.  So the constructor gets the value of the FDataLink defined in the parent class with its somewhat odd “GetValue(self)” syntax.  This takes the RTTI field object, which understands members of a class, and gives it an instance (self) to retrieve the value from.  After that, we can add new event handlers for OnDataChange and OnUpdateData.  I also redefined the default Style property because if you have a combo box with a predefined list of options that the user is supposed to choose from, sticking an edit control onto it is just asking for trouble from the user-interface perspective.

Now that we’ve overcome the difficulty of getting at the datalink, how do we set up the data-aware properties of the control?  Sort of like this:

procedure TDBIndexComboBox.DataChange(Sender: TObject);
begin
  if not (Style = csSimple) and DroppedDown then Exit;
  if (FDataLink.Field <> nil) and (FDataLink.Field is TNumericField) then
    self.ItemIndex := FDataLink.Field.AsInteger
  else
    if csDesigning in ComponentState then
      SetComboText(Name)
    else
      SetComboText('');
end;

procedure TDBIndexComboBox.UpdateData(Sender: TObject);
begin
  if FDatalink.Editing then
     FDataLink.Field.AsInteger := self.ItemIndex;
end;

DataChange gets called when the data field changes, to update the control.  This is mainly a copy of the original TDBComboBox.DataChange, except for the second and third lines of the method.  First, we want to restrict it to only numeric fields, since ItemIndex doesn’t make much sense as a string or a boolean.  Using a non-numeric field will cause the control to appear inactive.  Then, instead of the original “SetComboText(FDataLink.Field.Text)”, we want to change the item index instead.  The UpdateData is similarly straightforward.  No type-checking here, though if you want it it shouldn’t be too difficult to put some in.

Unfortunately, the SetComboText method is also private, and private methods, unlike private fields, don’t get RTTI generated for them.  So I ended up having to copy SetComboText (and GetComboText, which it references) verbatim from the parent class.  The way these two are set up, they look like they should be the read and write specifiers for a protected (or even public) ComboText property, but they aren’t.  Even so, that’s a lot better than what I’d have had to do if there was no way to get at the FDataLink field.  The workarounds required for that would probably involve reimplementing the entire class, or at least a sizable fraction thereof.

I’m using this control in the TURBU project, and I’ll update the repository soon (probably tomorrow sometime) with the code for this.  I’ll also put it up as a standalone download here on TURBU Tech tomorrow.  What I’ve published here, though, should be enough to get the component working if you have D2010 and some knowledge of the fundamentals of custom component work.

Like it?  Hate it?  Think of some way I could improve on it?  Let me know in the comments!

As programmers, we often have near-absolute power on a computer.  We have access to everything that’s not specifically denied to us by system security, and with that much power comes great responsibility.  It’s important to remember what I consider the first principle of programming ethics:  When you write a program for someone else to use, the computer they are running it on is their property, not yours, and your program needs to behave itself accordingly.

There’s a negative corollary to the Golden Rule that applies here.  Do not unto others as you would not have them do unto you. Much like a surgeon whose power over a patient in his care is similarly near-absolute, we have the implicit responsibility to “first, do no harm.”  Your program needs to behave itself as an invited guest in someone else’s home.  You do not walk in and act like you own the place, and this has implications far beyond simply avoiding virus-like behavior.

For example, unless you’re writing for a very old computer, or for a few particularly backwards modern devices, such as the iPhone or most game consoles, your program is going to have to share the system with a bunch of other programs, and they need to execute too.  This means that you need to be careful to accomplish your task while using as few system resources as possible so you don’t end up hogging resources that another program may need.  If possible, keep your CPU and memory usage low.  This also means, for example, that it’s a very bad idea to use a garbage collector that’s designed to build up as much garbage as possible before collecting. That’s like never putting anything in the dishwasher until you have no clean dishes left in the house.  (And I’m sure some of you out there have kids that do exactly that.  Doesn’t it drive you up the wall?  Do you really want a program doing that on your computer?  If not, don’t do it to other people’s computers.)

Then there’s “protection.”  Most programmers tend to be pretty good about this sort of issue, until the idea of someone doing unauthorized things with their program comes up, and then all rational thought, not to mention consideration for ethics, goes right out the window, seemingly replaced by testosterone-driven outrage from coders who are usually rather mild and easygoing.  “What?!?  They’ll never get away with stealing my program!”  And then they proceed to do all sorts of blatantly evil things to other people’s computers.

Like most emotional knee-jerk reactions, this approach ignores the actual facts of the matter.  For example, empirical evidence suggests that, in the absence of any enforcement, almost 90% of people tend to be basically honest. That’s pretty darn good, even before you figure in the additional cost of actually providing the enforcement.

Also, copy protection simply does not work, due to a combination of two factors.  First, in order for the program to actually run, or for protected data to be read by a program, there has to be a “door” in the copy protection someplace.  Not a secret “backdoor,” just the ordinary variety that lets the authorized user through.  Thing is, if that exists in a computer-readable format, some user can find it and figure out how it works.  There are some coders out there who can read assembly as easily as you and I can read the language of our choice, and if one of them tries to find a hole in your protection, it won’t last long, and this is a very important point.

DRM proponents often say that a copy-protection scheme doesn’t have to be perfect; just good enough to discourage casual hackers and “keep honest people honest.”  The part about keeping honest people honest is nonsense, of course.  Either someone is honest or they aren’t.  But the thing is, so is the part about it not having to be perfect.  That might have been true twenty years ago, but today a copy-protection scheme has to be absolutely perfect, because if it’s cracked once, by anyone anywhere, it’s all over.  The crack will be posted online and any of those 13% or so of dishonest people out there who wants to use your program for free will have immediate access to it at the cost of just a little bit of searching.

And then there are the ethical issues involved.  In any other context, an external programmer taking control of the functionality of a computer away from the computer’s owner and using it against the owner’s interests is known as computer hacking, (or cracking if you prefer to use the term “hacker” in its original, positive context,) and is quite illegal.  Why all the special pleading in the case of DRM?  Because there’s lost revenue involved?  When did ensuring revenue become more a important consideration than not committing a crime?  Follow that line of reasoning far enough and you end up with Enron and Bernie Madoff, or the Sony rootkit.

We’re beginning a new year, and it’s traditional to set resolutions.  I hope everyone involved in programming will resolve to try to hold ourselves to the high standard of not writing code to do anything on another person’s computer that we wouldn’t want done on ours, and also to the even higher standard of actually thinking through the implications of what we try to do to figure out whether or not it would end up doing something bad.  Then maybe we’ll end up with a few less questions like that on StackOverflow, and I won’t have to keep posting the same answer to them.

Happy New Year, everyone!

Getting inside a generic list, though, was a bit of a hack.  Since Delphi 2010 doesn’t support covariance and contravariance on generic classes, you can’t take a routine that accepts “a TList<T>” and enumerate over all its contents, even if you constrain T to only descendants of a specific base class.  What I ended up doing is kinda ugly:

procedure TDatafile.uploadList(db: TDataset; const value: TValue; fieldname: string);

   function isUploadable(method: TRttiMethod): boolean;
   var
      param: TArray<TRttiParameter>;
      enumerator: TRttiType;
      prop: TRttiProperty;
      retval: TRttiType;
   begin
      result := false;
      param := method.GetParameters;
      if not (length(method.GetParameters) = 0) then
         Exit;
      enumerator := method.ReturnType;
      if not assigned(enumerator) then
         Exit;
      prop := enumerator.GetProperty('current');
      if not assigned(prop) then
         Exit;
      retval := prop.PropertyType;
      result := (retval is TRttiInstanceType);
   end;

var
   iType: TRttiInstanceType;
   enumMethod: TRttiMethod;
begin
   assert(value.Kind = tkClass);
   iType := FContext.GetType(value.TypeInfo) as TRttiInstanceType;
   enumMethod := iType.GetMethod('GetEnumerator');
   assert(assigned(enumMethod) and (isUploadable(enumMethod)));
   uploadEnumerable(db, value, enumMethod, fieldname);
end;

procedure TDatafile.uploadEnumerable(db: TDataset; const value: TValue;
  uploadMethod: TRttiMethod; fieldName: string);
var
   enumerator: TObject;
   enumType: TRttiType;
   current: TRttiProperty;
   moveNext: TRttiMethod;
   datafile: TDatafile;
begin
   enumerator := uploadMethod.Invoke(value, []).AsObject;
   enumType := FContext.GetType(enumerator.ClassInfo);
   current := enumType.GetProperty('Current');
   moveNext := enumType.GetMethod('MoveNext');

   while moveNext.Invoke(enumerator, []).AsBoolean do
   begin
      datafile := current.GetValue(enumerator).AsType<TDatafile>;
      db.Append;
      datafile.upload(db);
   end;
   if db.state in dsEditModes then
      db.Post;
   enumerator.Free;
end;

There’s some unrelated code mixed in which is specific to the way I’m uploading the objects to the datasets, but this is mainly about enumerating a generic list of an unknown type.  Basically, we’re doing manually what the language-level enumerator support does automatically, extracting and validating the enumerator and running the enumeration by hand.  Scary, no?  There’s gotta be a better way.

What I’d really like to see is something like this.  TRttiStructuredType (the base class for TRttiRecordType, TRttiInstanceType and TRttiInterfaceType) should get two methods:

function TRttiStructuredType.IsEnumerable: boolean;

function TRttiStructuredType.GetEnumerator: TRttiEnumerator; //returns nil if IsEnumerable is false

The TRttiEnumerator would basically do what my code above does: crack open the underlying type’s enumerator and run it, returning an enumerated sequence of TRttiObject objects.  But in order for that to work well, (without the sort of ugly hacks you see above,) it needs compiler-level support.  Maybe we can hope to see it in D2011?

Sound familiar? It should. You probably do it all the time. It’s an as-cast.

…what? You thought I was going to say “assertion”? Good point! An as-cast is a whole lot like an assertion. There’s one big difference, though. When an assertion fails, your error log ends up giving you some very useful (and easily customizable) information about the nature of the error. With an as-cast failure… nothing.  Granted, any decent error-logging framework will give you the unit name and line number anyway, but assertions still offer custom error messages that can make maintenance easier. (And, if your app doesn’t have an error-logging framework installed, the assertion failure can point you directly to whatever’s going wrong faster than just about anything else.)

Now I’m not saying that as-casts are bad. They can be useful, just like assertions can. But I often see code that uses as-casts when they’re not needed, and it feels like cargo cult programming to me. For example, have you ever seen (or written) a construct like this?

if sender is TMyObject then
  (sender as TMyObject).DoSomething;

What’s wrong with this picture?  Let’s look at what an as-cast does.  From system.pas:

function _AsClass(Child: TObject; Parent: TClass): TObject;
{$IFDEF PUREPASCAL}
begin
  Result := Child;
  if not (Child is Parent) then
    Error(reInvalidCast);   // loses return address
end;

I’ll skip the assembly version, though it’s worth noting that the PUREPASCAL reference code isn’t completely accurate.  (Think about how it would handle a nil object reference.)  But it’s close enough.  If we substitute the code into my example, we get this:

if Sender is TMyObject then
  begin
    if not (Sender is TMyObject) then
      Error(reInvalidCast);   // loses return address
  end;
TMyObject(Sender).DoSomething;

Why are we calling is twice? Unless some other thread is replacing one object with another in between the two lines, there’s nothing to worry about, and if you do have threads behaving that way, you’ve got bigger issues to worry about.  But even so, does it really matter?  Would that be a bad thing to do?  Well, with all due credit to Bill Clinton, that depends on what the definition of is is.  Fortunately, it’s defined in system.pas, right above the definition of as.  It simply checks for nil, then calls InheritsFrom on the object.  So what does InheritsFrom do?  Here’s the PUREPASCAL version:

class function TObject.InheritsFrom(AClass: TClass): Boolean;
{$IFDEF PUREPASCAL}
var
  ClassPtr: TClass;
begin
  ClassPtr := Self;
  while (ClassPtr <> nil) and (ClassPtr <> AClass) do
    ClassPtr := PPointer(Integer(ClassPtr) + vmtParent)^;
  Result := ClassPtr = AClass;
end;

It’s basically doing a linear search of a linked list, which runs in O(n) time and isn’t particularly cache-friendly.  Not much to worry about, though, unless you do it in a tight loop.  But when you do, the results can be informative.  One thing I didn’t mention in my post a few weeks ago about optimizing a routine at work was the impact of as-casts. I didn’t mention it because it became irrelevant once I removed the horrendously inefficient comparison double-loop, but when it was there, the profiler found that 15% of the time was spent in System._AsClass.  Why?  Because our ORM object list was doing an as-cast in its Get routine.

You’ve probably seen custom object lists before, wrappers around TObjectList that only hold certain kinds of objects.  This was one of those, and on its Get routine it did something like this:

function TOrmObjectList.Get(index: integer): TOrmObject;
begin
   result := inherited Get(index) as TOrmObject;
end;

Our inheritance tree was pretty deep, and so every time it tried to retrieve an object from the list, it had to walk a linked list 6 or 7 steps before arriving at the base class the as-cast was looking for. Do that a few million times and it starts to really add up. And the thing is, it wasn’t even needed there because the Put method would only accept TOrmObject instances anyway. The compiler’s type safety made the cast redundant, and I ended up replacing it with a hard cast. (And yes, there’s always the possibility of memory corruption. But in my experience, if a bad pointer ends up stomping your RAM and writing over your data, the likelihood that whatever essentially random bytes overwrite your object reference will also be a pointer to a valid object of a different class is extremely low, and an as-cast in this case is far more likely to produce an access violation than an EInvalidCast exception. This will become even more true when we go to 64 bits and the size of a pointer doubles.)

Again, as-casts aren’t bad. I’ve caught a fair number of errors with them, and I’d be the last to say they’re “considered harmful” or anything like that. But using them when there’s no need for one doesn’t actually improve safety and can result in significant performance hits if it’s used in a tight loop. A hard cast has zero performance impact at runtime. No code is generated for it; it’s just there to satisfy the compiler’s type safety rules. So when you write your typecasts, ask yourself if you really need an as-sertion here.

procedure ContrivedExample;
var
   factorial: TFunc;
begin
   factorial :=
      function(input: Integer): integer
      begin
         if (input = 0) or (input = 1) then
            result := input
         else result := input * (factorial(input - 1));
      end;

   writeln(factorial(5));
end;

Or how about this one, which doesn’t use recursion, and is based on something I noticed when using the list comparison algorithm to solve a problem at work?

procedure SomewhatLessContrivedExample(list1, list2: TList);
var
   newItem, editItem, deleteItem: TProc;
begin
   newItem :=
      procedure(value: TMyObject)
      begin
         fMainList.Add(value);
      end;

   editItem :=
      procedure(value: TMyObject)
      begin
         if value.CheckSomeFlag = true then
            newItem(value)
         else fMainList[value.id].Update(value);
      end;

   deleteItem :=
      procedure(value: TMyObject)
      begin
         fMainList.Delete(value);
      end;

   listCompare(list1, list2, editItem, newItem, deleteItem);
end;

If you were paying close attention in my first two posts about how anonymous methods are implemented, you might realize that these anonymous method references are interface references to a TInterfacedObject descendant, and that by having the closure capture one, the object now holds a reference to itself.  Which means that when you actually run the code, you could end up with FastMM4 reporting something like this:

An unexpected memory leak has occurred. The unexpected small block leaks are:
21 – 28 bytes: ContrivedExample$ActRec x 1

Oops!  That’s not good, especially if you call ContrivedExample in a main loop somewhere and end up leaking hundreds of thousands of them.  This is too bad, since there are all sorts of interesting things you could do by using anonymous methods recursively.  And since anonymous methods don’t have a name, they can’t invoke themselves recursively without capturing the reference variable.

There’s probably no way for the compiler to prevent this in the general case, but it could be solved easily enough for examples that fit the pattern described in my examples:  When an anonymous method reference variable is only assigned once in an enclosing procedure, and that one point is where the method is defined within the procedure (i.e. it’s not passed in as a parameter or already assigned at global or object scope), then the compiler can be certain that the Self pointer for the underlying object is the same as the one it’s currently executing on, and transform it behind the scenes from an interface reference to a normal method call.

Can anyone else think of possible ways to fix this?

Verification takes place in four steps:

1. Load the data from the files
2. Process the data
3. Process the data some more
4. Retrieve the results

Steps 3 and 4 only take a few seconds each.  Step 2 takes a couple minutes, but the bulk of the time is spent in step 1.  So I decided to focus on there to see if I could find what was making it take so long.  First thing to do is establish a baseline. I built the old version and turned on SQL Server Profiler for the database and Sampling Profiler, an excellent tool written in Delphi that helps you profile Delphi apps without slowing them down the way AQTime does.  I ran the entire verification process and found that yes, not only was step 1 taking most of the time, over 90% of the time was spent on one single line that matches the data from the files against the data in the database.

The data-loading system looks something like this.  Names and a few details have been changed to protect the innocent the corporate intellectual property, of course, but this is the general idea of what was going on.  See how many problems you can spot in this code.  (Bear in mind, this was the original, faster version.)

procedure TVerificationDataModule.LoadFile(const filename: string;
                                           otherParams: TOtherData);
var
   lines: TStringList;
   fileData: TObjectList
   dbData: TOrmObjectList;
   i: integer;
begin
   lines := TStringList.Create;
   fileData := TObjectList.Create;
   try
      lines.LoadFromFile(filename);
      for I := 0 to lines.Count - 1 do
         fileData.Add(parseLine(lines[i]));
   finally
      lines.Free;
   end;

   dbData := GetRelevantDBData(otherParams);
   try
      for i := 0 to fileData.Count - 1 do
         MatchFileDataAgainstDB(fileData[i] as TFileData, dbData);
   finally
      dbData.Free;
   end;
end;

procedure TVerificationDataModule.MatchFileDataAgainstDB(fileData: TFileData;
                                                         dbData: TOrmObjectList);
var
   i: integer;
   dbItem: TOrmVerificationObject;
   updateProcedure: IStoredProcedureRecord;
begin
   for i := 0 to dbData.Count - 1 do
   begin
      dbItem := dbData[i] as TOrmVerificationObject;

      //90% of time is spent on this next line:
      if fileData.param1 = dbItem.param1 and
         fileData.param2 = dbItem.param2 and
         fileData.param3 = dbItem.param3 and
         fileData.param4 = dbItem.param4 then
      begin
         updateProcedure := CreateStoredProc('VERIFICATION_DATA_LOADER');
         updateProcedure.param1 := fileData.param3;
         updateProcedure.param2 := fileData.param4;
         updateProcedure.param3 := fileData.param5;
         updateProcedure.param4 := fileData.param6;
         updateProcedure.param5 := fileData.param7;
         updateProcedure.Execute;
         if updateProcedure.ResultCode <> GOOD_RESULT then
            raise Exception.Create('Something went wrong');

         dbData.Delete(i);
      end;
   end;
end;

Then I profiled the newer version and got very similar results, except that it was spending even more time in the if statement to match the objects against each other.  Close to 99% now.  So what had changed?  I looked back through version control and found that the SQL that generates the result set that goes into dbData had been changed between versions.  A new table was added to simplify the big mess of joins, but they forgot one of the on criteria, so it was returning three times as many results as it should have.  There’s your factor of three right there.  Easy enough to fix.  But that still doesn’t address the quality of the original code.  A couple things jumped right out at me, and I wondered if I could bring the time down below the original mark.

The first thing came out of the SQL profiler.  I kept seeing a call to sp_procedure_params_rowset, an undocumented procedure in SQL Server that the connection object uses internally to get information about the expected parameters for a stored procedure, immediately followed by a call to the VERIFICATION_DATA_LOADER proc.  This seemed a bit silly to me.  The signature of the stored procedure isn’t going to change!  Turns out that was called internally by the CreateStoredProc function, which was being called every time it went to save some data to the database, in order to create the proper object.

So I moved the call to CreateStoredProc out to the main procedure and set it up as an extra parameter to pass into MatchFileDataAgainstDB.  It would reuse the same basic stored procedure object and reassign its parameters for each call, so you get the same net effect, but with 50% less database hits.  Unfortunately, this didn’t yield a 50% increase in performance.  SQL Server can cache the results of redundant queries, so this call wasn’t taking much time at all to process repeatedly, but the transport layer overhead was still a factor, and removing this redundant call sped the overall process up by about 20%.

But the big one was in the matching, where the profiler said the system was spending the majority of its time.  It doesn’t exactly look like a speed bottleneck, because it’s stored inside a method call, but what it is is a linear search inside of a loop, with both lists containing a few thousand elements each.  But how do you make something like this run faster?  I could try sorting the second list and using a binary search, but have you ever written a binary search?  It’s a bunch of extra code, and it’s often confusing and hard to read.  I couldn’t use a TDictionary to index the second list, because I need to match against 4 items, not just 1.  So instead I used a very simple trick that’s been around for decades but I don’t tend to see very often these days: list comparison.

The general algorithm goes like this:

1. Sort both lists by the same criteria.  This must also be the same as the matching criteria.
2. Start at the top of both lists.  Pick the first item from each and compare them.
3. If they match, handle the case and advance the index for both lists.
4. If they don’t match, loop through, advancing the index for the list with the “lesser” value each time, until a match is found.
5. When you reach the end of either list, you’re done.  (Unless you want to handle any leftovers from the other list.)

This is a very simple and very useful algorithm for reconciling two sets of data, and I’ve managed to find all sorts of uses for it.  Unlike a double-nested loop, which basically runs in quadratic time,  this is guaranteed to run in linear time and never walk either list more than once.  I managed to adapt this algorithm to the existing code, and suddenly processing the input files, which had previously taken at least a minute each, takes between 2 and 6 seconds per file.  Now loading the data takes about the same amount of time as performing the calculations, instead of an order of magnitude longer.

Lessons learned:

• Profilers, especially non-invasive ones, are invaluable for finding what’s going on in your app.  I’d have probably noticed that double-nested loop soon enough, but I would never have found the stored procedure issue without SQL Server Profiler to point it out.
• Pulling things out of loops—especially other loops!—is a great way to increase performance.
• Reducing algorithmic time complexity is by far the best optimization for large data sets.
• Linear, single-threaded techniques are still relevant.  A lot of people are talking these days about parallel programming and how the meaning of optimization has changed in today’s world.  They’re right, to a certain extent, but as hard as I try I can’t think of any way to parallelize this check that would make it faster than a simple list comparison.  The only thing I know of with the potential to be faster than this is a hash table lookup, which could be parallelized, but it won’t work particularly well when you need to look up your values based on more than one index value.