Optimization Report
|
|
Top Previous Next |
|
Targets: All
This report pinpoints elements of the code that you can improve, resulting in better performance. With better performance, we here mean faster execution, not necessarily smaller code.
Sections:
OPTI1-Missing “const” for unmodified string parameter OPTI2-Missing “const” for unmodified record parameter OPTI3-Missing "const" for unmodified array parameter OPTI4-Array properties that are referenced/set within methods OPTI5-Virtual methods (procedures/functions) that are not overridden
OPTI6-Local subprograms with references to outer local variables OPTI7-Subprograms with local subprograms OPTI8-Parameter is "var", can be changed to "out" OPTI9-Inlined subprograms not inlined because not yet implemented OPTI10-Managed local variable can be declared inline OPTI11-Managed local variable is inlined in loop
OPTI1-Missing “const” for unmodified string parameter
This is a list of all string parameters that you can declare with the const directive, resulting in better performance since the compiler can assume that the parameter will not be changed. For example, for a long string the reference count for the string does not need to be updated on entry and exit to the function. For other types of strings, like WideString, the string may have to be copied when passed to the function.
Example:
In this case, the parameter S should have the const directive, since it is never changed in the procedure. The compiler can generate code that is more efficient.
No warning is given for methods that are marked with the "override" directive. This is because they must follow the parameter list that the overridden method has.
__________________________________________________
OPTI2-Missing “const” for unmodified record parameter
This is a list of all record parameters that you can declare with the const directive, resulting in better performance since the compiler can assume that the parameter will not be changed. Generally, if the parameter is larger than 4 bytes, and it doesn't need to be altered in the subroutine, const is more efficient. Also, it is a good idea to use CONST on parameters that aren't intended to be altered, so the compiler can catch those errors for you.
Example:
In this case, the parameter R should have the const directive, since it is never changed in the procedure. The compiler can generate code that is more efficient.
No warning is given for methods that are marked with the "override" directive. This is because they must follow the parameter list that the overridden method has.
__________________________________________________
OPTI3-Missing "const" for unmodified array parameter
This is a list of all array parameters that you can declare with the const directive, resulting in better performance since the compiler can assume that the parameter will not be changed.
No warning is given for methods that are marked with the "override" directive. This is because they must follow the parameter list that the overridden method has.
__________________________________________________
OPTI4-Array properties that are referenced/set within methods
This is a list of all array properties that are referenced or set within methods of a class. Methods that include a reference to the property are listed.
For performance reasons it is faster to directly access the private array field. However, if the Get- or Set-method performs side effects, it makes sense to access the property.
For simple non-array properties, the compiler generates the same code for both access of the property or the field. Therefore, for normal properties there is no advantage in referencing the private field.
Example:
__________________________________________________
OPTI5-Virtual methods (procedures/functions) that are not overridden
This is a list of all methods that are declared as virtual, but that never are overridden. Since virtual methods have slightly worse performance than static methods, it is better to change these methods to static ones instead.
This section is also generated for multi-projects.
Recommendation:
Examine if these methods should really be overridden. If they belong to a base class, you should probably keep them virtual, so descendant classes can create their own implementations.
__________________________________________________
OPTI6-Local subprograms with references to outer local variables
This section shows nested local procedures, with references to outer local variables. Those local variables require some special stack manipulation so that the variables of the outer routine can be seen by the inner routine. This results in a good bit of overhead.
__________________________________________________
OPTI7-Subprograms with local subprograms
This section lists subprograms that themselves have local subprograms. Especially when these subprograms share local variables, it can have a negative effect on performance.
__________________________________________________
OPTI8-Parameter is "var", can be changed to "out"
This section lists parameters that are marked with the "var" directive, but that can be changed to "out". Even if it may not improve performance, it improves the readability of the code and makes its intentions clearer.
__________________________________________________
OPTI9-Inlined subprograms not inlined because not yet implemented
This section lists calls to inlined subprograms, where the subprogram will not be inlined. The reason is that the subprogram has not been implemented yet. It is implemented further down in the same module. There are a number of other conditions that also must be fulfilled for the subprogram to be inlined.
To make the subprogram inlined for this call, make sure that it is implemented higher up in the same module.
OPTI10-Managed local variable can be declared inline
This section lists local variables that instead of being declared in the main var-section, can be declared inline. Doing so optimizes the initialization-finalization code that is executed, and now only needs to be done when certain conditions are fulfilled.
Managed variables are strings, interfaces, dynamic arrays and records that contain managed fields.
Inline variable declarations were introduced in Delphi 10.3, so this report section is not relevant for older targets.
OPTI11-Managed local variable is inlined in loop
This section lists local variables that instead of being declared in the main var-section, are declared inline. They are declared inside a loop, which decreases performance. The reason is that initialization-finalization of the variable has to be done for each loop iteration.
Managed variables are strings, interfaces, dynamic arrays and records that contain managed fields.
Inline variable declarations were introduced in Delphi 10.3, so this report section is not relevant for older targets.
See also:
|
