Question

My setting:

• OS: Windows 7 SP1 (32 bits)
• Ram: 4 Go
• Processor: Intel Pentium D 3.00 GHz
• Delphi XE

My simple test:

I performed a test running the following program:

program TestAssign;

{$APPTYPE CONSOLE}

uses
  SysUtils,
  Diagnostics;

type
  TTestClazz = class
  private
    FIntProp: Integer;
    FStringProp: string;
  protected
    procedure SetIntProp(const Value: Integer);
    procedure SetStringProp(const Value: string);
  public
    property  IntProp: Integer   read FIntProp write SetIntProp;
    property  StringProp: string read FStringProp write SetStringProp;
  end;

{ TTestClazz }

procedure TTestClazz.SetIntProp(const Value: Integer);
begin
  if FIntProp <> Value then
    FIntProp := Value;
end;

procedure TTestClazz.SetStringProp(const Value: string);
begin
  if FStringProp <> Value then
    FStringProp := Value;
end;

var
  i, j: Integer;
  stopw1, stopw2 : TStopwatch;
  TestObj: TTestClazz;

begin
  ReportMemoryLeaksOnShutdown := True;
  //
  try
    TestObj := TTestClazz.Create;
    //
    try
      j := 10000;

      while j <= 100000 do
      begin
        ///
        /// assignement
        ///
        stopw1 :=  TStopwatch.StartNew;
        for i := 0 to j do
        begin
          TestObj.FIntProp := 666;
          TestObj.FStringProp := 'Hello';
        end;
        stopw1.Stop;

        ///
        /// property assignement using Setter
        ///
        stopw2 := TStopwatch.StartNew;
        for i := 0 to j do
        begin
          TestObj.IntProp := 666;
          TestObj.StringProp := 'Hello';
        end;
        stopw2.Stop;

        ///
        /// Log results
        ///

        Writeln(Format('Ellapsed time for %6.d loops: %5.d %5.d', [j, stopw1.ElapsedMilliseconds, stopw2.ElapsedMilliseconds]));

        //
        Inc(j, 5000);
      end;
      //
      Writeln('');
      Write('Press Return to Quit...');

      Readln;
    finally
      TestObj.Free
    end
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;
end.

My (provisionnal) conclusion:

It seems that:

• It’s worth using Setter with property under some condition
• The overhead of calling a method and performing a conditional test take less time than an assignement.

My question:

Are those findings valid under any other diffrent setting or just localized ones (exception)?

Answer 1

I would make the following observations:

1. The decision as to whether or not to use a setter should be based on factors like code maintenance, correctness, readability rather than performance.
2. Your benchmark is wholly unreasonable since the if statements evaluate to False every time. Real world code that sets properties would be likely to modify the properties a reasonable proportion of the time that the setter runs.
3. I would expect that for many real world examples, the setter would run faster without the equality test. If that test were to evaluate to True every time then clearly the code would be quicker without it.
4. The integer setter is practically free and in fact the setter is slower than the direct field access.
5. The time is spent in the string property. Here there is some real performance benefit due to the optimisation of the if test which avoids string assignment code if possible.
6. The setters would be faster if you inlined them, but not by a significant amount.

My belief is that any real world code would never be able to detect any of these performance differences. In reality the bottleneck will be obtaining the values passed to the setters rather than time spent in the setters.

The main situation where such if protection is valuable is where the property modification is expensive. For example, perhaps it involves sending a Windows message, or hitting a database. For a property backed by a field you can probably take it or leave it.

---

In the chatter in the comments Premature Optimization wonders why the comparison if FStringProp <> Value is quicker than the assignment FStringProp := Value. I investigated a little further and it wasn’t quite as I had originally thought.

It turns out that if FStringProp <> Value is dominated by a call to System._UStrEqual. The two strings passed are not in fact the same reference and so each character has to be compared. However, this code is highly optimised and crucially there are only 5 characters to compare.

The call to FStringProp := Value goes to System._UStrAsg and since Value is a literal with negative reference count, a brand new string has to be made. The Pascal version of the code looks like this:

procedure _UStrAsg(var Dest: UnicodeString; const Source: UnicodeString); // globals (need copy)
var
  S, D: Pointer;
  P: PStrRec;
  Len: LongInt;
begin
  S := Pointer(Source);
  if S <> nil then
  begin
    if __StringRefCnt(Source) < 0 then   // make copy of string literal
    begin
      Len := __StringLength(Source);
      S := _NewUnicodeString(Len);
      Move(Pointer(Source)^, S^, Len * SizeOf(WideChar));
    end else
    begin
      P := PStrRec(PByte(S) - SizeOf(StrRec));
      InterlockedIncrement(P.refCnt);
    end;
  end;
  D := Pointer(Dest);
  Pointer(Dest) := S;
  _UStrClr(D);
end;

The key part of this is the call to _NewUnicodeString which of course calls GetMem. I am not at all surprised that heap allocation is significantly slower than comparison of 5 characters.