Articles Inline Variables can increase performance by Erik van Bilsen

emailx45 · 1 Май 2020

Inline Variables can increase performance
November 2018 Erik van Bilsen

[SHOWTOGROUPS=4,20]
Delphi 10.3 Rio will add inline variables to the language. Besides the various benefits mentioned in Для просмотра ссылки Войди или Зарегистрируйся, inline variables can potentially improve performance of your code.
It’s all about scope
If you have been reading my articles, then you may know that I am a sucker for performance. That’s one of the reasons I am very excited about this addition to the Delphi language. Для просмотра ссылки Войди или Зарегистрируйся does an excellent job at explaining the syntax at benefits, so I will not go into that here. Instead, lets jump right into an example. Consider the following (“classical”) code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

type
TFoo = record
I: Integer;
S: String;
end;

procedure TestLocalVars(const ACondition: Boolean);
var
S: String;
I: IInterface;
F: TFoo;
begin
if (ACondition) then
begin
S := 'Local String';
I := TInterfacedObject.Create;
F.S := 'Managed Record';
end;
end;

This code uses 3 local variables. In addition all these variables are “managed” variables, meaning that Delphi adds some code behind the scenes to manage initialization, cleanup, and assignment of these variables. A managed variable is a variable that is (implicitly or explicitly) reference counted, such as a string, dynamic array, object interface or a plain object on ARC platforms (Для просмотра ссылки Войди или Зарегистрируйся). A record that contains one or more managed fields is also a managed type, such as the TFoo type in this example.
All Delphi compilers (including the upcoming 10.3 version) convert this example to the following (pseudo) code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

procedure TestLocalVars(const ACondition: Boolean);
var
S: String;
I: IInterface;
F: TFoo;
begin
S := nil; // Added by compiler
I := nil; // Added by compiler
InitializeRecord(F); // Added by compiler
if (ACondition) then
begin
S := 'Local String';
I := TInterfacedObject.Create;
F.S := 'Managed Record';
end;
FinalizeRecord(F); // Added by compiler
IntfClear(I); // Added by compiler
UStrClr(S); // Added by compiler
end;

As you can see, Delphi implicitly adds initialization to the beginning of the routine to clear out the string and interface, and to initialize the managed record. At the end of the routine, it cleans up the record, interface and string. These routines basically check these variables for nil, and if they are not nil, it decreases their reference counts which could result in releasing their memory. These routines are not very expensive, but they are not cheap either. In particular, FinalizeRecord is a bit expensive since it uses RTTI to traverse all managed fields in the record and recursively clean them up.

Note that InitializeRecord and FinalizeRecord are only called for “managed” records (that is, records with any managed fields). For POD records, this overhead does not exist.

As you can see, the initialization and finalization code is always executed, even if ACondition is False. It would be more efficient if this code is only executed when the if-statement evaluates to True. This is where inline variables come to the rescue.

Limiting Scope with Inline Variables
The same example using inline variables can be rewritten to this:

1
2
3
4
5
6
7
8
9
10

procedure TestInlineVars(const ACondition: Boolean);
begin
if (ACondition) then
begin
var S := 'Inline String';
var I: IInterface := TInterfacedObject.Create;
var F: TFoo;
F.S := 'Managed Record';
end;
end;

Note that for the S variable, we can take advantage of type inference. This is not possible in this example for the I and F variables.

The new Delphi compiler converts this to the following (pseudo) code (at least ideally):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

procedure TestInlineVars(const ACondition: Boolean);
begin
if (ACondition) then
begin
var S: String := nil; // Added by compiler
S := 'Inline String';
var I: IInterface := nil; // Added by compiler
I := TInterfacedObject.Create;
var F: TFoo;
InitializeRecord(F); // Added by compiler
F.S := 'Managed Record';
FinalizeRecord(F); // Added by compiler
IntfClear(I); // Added by compiler
UStrClr(S); // Added by compiler
end;
end;

Now, the initialization and finalization code is only executed if necessary. This improves performance, especially of ACondition is usually False.

The code that Delphi actually generates is different for the pseudo-code presented here. It is not as efficient as it should be, but hopefully this will improve in the future.

This may be a bit of a contrived example, but I have run into several situations in the past where inline variables would have (considerably) improved performance. For example, our Для просмотра ссылки Войди или Зарегистрируйся library contains code to parse JSON files. At some point, it uses a case statement to perform specific actions depending on the type of the data element currently read. Most cases use temporary strings or interface variables, which would go through initialization and finalization code. However, only one case in the case statement would actually be executed, unnecessarily running the initialization and finalization code for all other temporary variables that weren’t used. This had a measurable negative impact on parsing performance. I fixed that by having each case in the case statement call a different routine, and declare those variables inside those routines only. While this may be good practice in many cases, in this case it actually hurt readability of the code. Inline variables would have been a much better solution!

Implicit Local Variables
While it may not always be obvious, Delphi regularly creates temporary local variables behind the scenes. Consider this fragment:

1
2
3
4
5

procedure TestImplicitLocalVar(const AValue: Integer);
begin
if (AValue <> 0) then
ShowMessage(Format('Value: %d', [AValue]));
end;

The Delphi compiler will add a temporary string variable here to store the result of the Format call. The actual (pseudo) code that Delphi generates is:

1
2
3
4
5
6
7
8
9
10

procedure TestImplicitLocalVar(const AValue: Integer);
begin
var Temp: String = nil; // Added by compiler
if (AValue <> 0) then
begin
Temp := Format('Value: %d', [AValue]); // Added by compiler
ShowMessage(Temp);
end;
UStrClr(Temp); // Added by compiler
end;

Notice that UStrClr is always called, whether AValue is 0 or not. This is especially bad if AValue is almost always 0. For example, this routine could check an error code and show an error message in case the code is not 0. In the vast majority of cases, the error code will be 0 and the calling this routine should be very cheap. However, it calls some implicit initialization and finalization code every time the routine is invoked, resulting in non-trivial overhead.

You can improve performance by making the implicitly added variable explicit, and turning it into an inline variable:

1
2
3
4
5
6
7
8

procedure TestExplicitInlineVar(const AValue: Integer);
begin
if (AValue <> 0) then
begin
var Temp := Format('Value: %d', [AValue]);
ShowMessage(Temp);
end;
end;

Now, the string is only initialized and cleaned up when AValue is not 0.

Ideally, Delphi would inline all implicitly generated temporary managed variables behind the scenes, so we would not have to take care of this ourselves. That would be a nice feature for a future update…

Use with Care
Now I am not saying that you should start modifying your existing code to use inline variables everywhere. It can definitely improve performance for routines that are called a lot or inside tight loops, but there are some drawbacks too.

Currently, inline variables can increase the size of the generated code, especially if they are of a managed type. This extra code also makes inline managed variables not as efficient as they could be. But then again, this is version 1.0 of this feature, so we could see improvements in the future.

Inline variables have a lot of potential when used wisely. Not only can they improve performance, they can also improve readability, maintainability and in some cases reliability of your code. As with everything, use them if it makes sense, but not just because they exist.

[/SHOWTOGROUPS]

Articles Inline Variables can increase performance by Erik van Bilsen

emailx45

Похожие темы