Micro optimization - effect of defined and not used local variables

[Mike Torrettinni 198]

During routine profiling I noticed a function that gets called 1mio+ times and I wanted to look into it, even though it's only 0.24% of total execution time. So, not a bottleneck, but still wanted to see is there anything need to be addressed.

 

Here is example that imitates a real function:

 

var flag: boolean = true;

function ProcessString(const aStr: string): string;
var s: string;
    i: integer;
    b: boolean;
begin
  if flag then
    Exit(aStr);
  
  // dummy code to use the local variables
  s := aStr;
  i := Length(s);
  b := i = 1;
  if b then
    Result := aStr
  else
    Result := s;
end;

As this function will always return string and exit, the same does my real function in 99.9% cases -  in only 0.01% cases executes the lower part of the function.

 

If I split functions to this:

function ProcessStringOLD(const aStr: string): string;
var s: string;
    i: integer;
    b: boolean;
begin
  s := aStr;
  i := Length(s);
  b := i = 1;
  if b then
    Result := aStr
  else
    Result := s;
end;

function ProcessStringNew(const aStr: string): string;
begin
  if flag then
    Exit(aStr)
  else
    Result := ProcessStringOLD(aStr);
end;

In this case, the new ProcessStringNew is 25% faster, because it never executes ProcessStringOLD - make sense.

 

But if I set the flag = false, then of course ProcessStringNew is slower vs original ProcessString, but only by 7%.

 

So new changes result in: 25% faster in 99.9% and 7% slower in 0.01%.

 

Does this micro optimization makes sense? I assume a few little changes like this across in multiple functions, and it could save some valuable execution time, >1%.

[Rollo62 536]

You could remove the flag, by the use of a PointerVariable as pointer to function.

In SetFlag, you can switch the PointerVariable to the desired, real function, so that the PointerVariable always willl be valid.

Then just calling the PointerVariable will not need any conditional check inside.

Edited November 25, 2020 by Rollo62

[Attila Kovacs 629]

21 minutes ago, Mike Torrettinni said:

In this case, the new ProcessStringNew is 25% faster, because it never executes ProcessStringOLD - make sense.

Wrong.

It's faster because you don't have a managed type as a local variable.

 

7 minutes ago, Rollo62 said:

a PointerVariable

a procedural type would be enough, no pointer needed

[Anders Melander 1783]

22 minutes ago, Mike Torrettinni said:

Does this micro optimization makes sense?

No I don't think so. You've just made your code more complex and harder to maintain and gained almost nothing.

[Mike Torrettinni 198]

19 minutes ago, Rollo62 said:

You could remove the flag, by the use of a PointerVariable as pointer to function.

In SetFlag, you can switch the PointerVariable to the desired, real function, so that the PointerVariable always willl be valid.

Then just calling the PointerVariable will not need any conditional check inside.

 

11 minutes ago, Attila Kovacs said:

a procedural type would be enough, no pointer needed

Are you guys suggesting that I set the function type at the time when I set the flag (SetFlag), something like:

 

flag := SetFlag; // flag is initialize on Project start
if flag then 
  ProcessString := ProcessStringWhenFlagIsTrue
else
  ProcessString := ProcessStringWhenFlagIsFalse;
  
// function type
type
TProcessStringType = function(const aStr: string): string;

ProcessString = TProcessStringType;
  
  
// usage of ProcessString function
  vStr := ProcessString('x');

?

[Attila Kovacs 629]

Only if it make sense. (Not for every call)

We don't know how your code work.

[Mike Torrettinni 198]

2 minutes ago, Attila Kovacs said:

Only if it make sense. (Not for every call)

We don't know how your code work.

OK, thanks, interesting suggestion. In this case this could work, because flag doesn't change while the project is running, set at the beginning for the whole runtime of project.

[Guest]

37 minutes ago, Mike Torrettinni said:

Does this micro optimization makes sense?

It is just ugly, and the benefit is limited per your timing.

 

There is a trick which is also ugly but more handsome !

 

The overhead of using string as local var in often called function might be small but can accumulate, so only if you want it, and for educational knowledge as trick and workaround, you can do the following:

 

function ProcessString(const aStr: string; var unused: string): string;
var
  i: integer;
  b: boolean;
begin
  if flag then
    Exit(aStr);

  // dummy code to use the local variables
  unused := aStr;
  i := Length(unused);
  b := i = 1;
  if b then
    Result := aStr
  else
    Result := unused;
end;

procedure TheOneThatCallProcessString;
var
  temp: string;
begin
  for ...
    ProcessString('12', temp)
end;

This should fix your gain from splitting the function in both flag cases, the idea is to remove local managed var from this function to a parent/caller local one, so no more try..finally then clearing, this only can be helpful when you have fairly small number of callers to that function.

[Mike Torrettinni 198]

9 minutes ago, Kas Ob. said:

This should fix your gain from splitting the function in both flag cases, the idea is to remove local managed var from this function to a parent/caller local one, so no more try..finally then clearing, this only can be helpful when you have fairly small number of callers to that function.

Aha, interesting. Now I understand what @Attila Kovacs meant in his comment:

 

37 minutes ago, Attila Kovacs said:

Wrong.

It's faster because you don't have a managed type as a local variable.

 

I was still focused on local unused variables vs no-local variables. Wasn't focused on string variable.

[Guest]

I forgot to mention when it is not ugly but appreciated for speed with minimal cosmetic effect.

When your function is a method in a class/record then move these local managed types vars to be private fields even when each one of them is not used outside one method, here you can recycle them, just remember they are initialized with some value from previous usage so be careful, like don't assume a string being used like that an empty one.

[Mike Torrettinni 198]

21 minutes ago, Kas Ob. said:

I forgot to mention when it is not ugly but appreciated for speed with minimal cosmetic effect.

When your function is a method in a class/record then move these local managed types vars to be private fields even when each one of them is not used outside one method, here you can recycle them, just remember they are initialized with some value from previous usage so be careful, like don't assume a string being used like that an empty one.

OK, thanks. Good suggestion on class encapsulation, if possible.

 

I'm not worried about ugly code, if I add comments and meaningful names, I'm OK with it, if it performs good. Of course such functions are rarely changed, so maintenance is also not really a deciding factor.

[Anders Melander 1783]

9 minutes ago, Mike Torrettinni said:

I'm not worried about ugly code, if I add comments and meaningful names, I'm OK with it, if it performs good. Of course such functions are rarely changed, so maintenance is also not really a deciding factor.

That's a very short sighted attitude. Technical debt accumulates and your memory will not get better with age, or so I've heard

[Mike Torrettinni 198]

3 minutes ago, Anders Melander said:

That's a very short sighted attitude. Technical debt accumulates and your memory will not get better with age, or so I've heard

My memory is already bad, just ask my wife 🙂

[Guest]

Quote

"Code you wrote 6 months ago could as well have been written by someone else".

 

So true and you will notice it even more when you have to "jump" between completely different projects (like a huge server project, a VCL based client, a JS/TypeScript project and so on and so forth... after a while you start to REALLY appreciate OPs strictness (well, at least most times). No, milliseconds that evolve to minutes per moth, in these cases both we and our clients might well be better served by maintainable code!!

Edited November 25, 2020 by Guest
Added an "oxford comma"

[Mike Torrettinni 198]

11 minutes ago, Dany Marmur said:

 

So true and you will notice it even more when you have to "jump" between completely different projects (like a huge server project, a VCL based client, a JS/TypeScript project and so on and so forth... after a while you start to REALLY appreciate OPs strictness (well, at least most times). No, milliseconds that evolve to minutes per moth, in these cases both we and our clients might well be better served by maintainable code!!

Thank you, but I think we have different definition of maintainable code. Until a few years ago I didn't use classes, I had 1000s of global variables, long methods, so nothing refactored...

And now you guys describing splitting this function into 2 functions for performance (or whatever reason) as ugly, non-maintainable code... we are so far apart on this, we are not even in the same zip code (or same country, for European friends) 🙂

 

I do appreciate all suggestions and comments! It would be nice to know if someone had similar experience, did similar thing, and how such micro optimization came back causing issues later.

[Guest]

15 minutes ago, Mike Torrettinni said:

you guys describing splitting this function into 2 functions for performance (or whatever reason) as ugly, non-maintainable code...

I did NOT write that. Most definitely not. I did not get close to the details above.

15 minutes ago, Mike Torrettinni said:

It would be nice to know if someone had similar experience, did similar thing, and how such micro optimization came back causing issues later

Where to start... but it takes an effort and time to produce a viable MVP for such a case (even if publishing is "just" here).

When it hits you, you fix the problem, swear (on yourself) and move on.

I seldom feel the need to document my own f¤ck&ps 🙂 i just move on. Experience will not sit better if i over-use notepads.

 

Sorry for being a "best practices" - "everything else is folly" kind of poster. There is two of us here now. Sorry, truly.

[Mike Torrettinni 198]

1 minute ago, Dany Marmur said:

I did NOT write that. Most definitely not. I did not get close to the details above.

Where to start... but it takes an effort and time to produce a viable MVP for such a case (even if publishing is "just" here).

When it hits you, you fix the problem, swear (on yourself) and move on.

I seldom feel the need to document my own f¤ck&ps 🙂 i just move on. Experience will not sit better if i over-use notepads.

 

Sorry for being a "best practices" - "everything else is folly" kind of poster. There is two of us here now. Sorry, truly.

No need for sorry, at all, really. When I was compared to a boy from 'Boy who cried wolf' story, it took me a while to realize how different personalities we have on this forum and to not take it personally, sometimes is just the language or wording 🙂

 

9 minutes ago, Dany Marmur said:

There is two of us here now

The usual trio of one-liners is not complete, in this topic, yet 🙂

 

Back to topic:

I didn't implement this change, yet, but will have it on the list to evaluate in the future. The Hex2Bin topic, from the other day, gave me a boost to try and see if little tricks make big improvements, but I rarely touch functions below 1% of total runtime, this one is more exception than the rule.

 

[Bill Meyer 337]

And as for one-liners:
"Premature optimization is the root of all evil in programming. "
- C. A. R. Hoare - often misattributed to D. E. Knuth,who was himself quoting Hoare

[Mike Torrettinni 198]

21 minutes ago, Bill Meyer said:

And as for one-liners:
"Premature optimization is the root of all evil in programming. "
- C. A. R. Hoare - often misattributed to D. E. Knuth,who was himself quoting Hoare

Nice try! 🙂

[Bill Meyer 337]

1 minute ago, Mike Torrettinni said:

Nice try! 🙂

There is another one out there, which hasn't turned up yet. Something to the effect that 90% of programmers are wrong 90% of the  time about where to optimize. 

[Mike Torrettinni 198]

5 minutes ago, Bill Meyer said:

There is another one out there, which hasn't turned up yet. Something to the effect that 90% of programmers are wrong 90% of the  time about where to optimize. 

I wasn't actually referring to these one-liners... 🙂

I would say I often try to optimize things that are 'fun', something I know I can do. If it's something very new to me, I hesitate but eventually go at it. So, 90% of the time is fun, I guess.

[Attila Kovacs 629]

"Premature optimization" is a phrase used to describe a situation where a programmer lets performance considerations affect the design of a piece of code. This can result in a design that is not as clean as it could have been or code that is incorrect, because the code is complicated by the optimization and the programmer is distracted by optimizing.

 

"Premature optimization is the root of all evil." December 1974

 

Test-driven development is related to the test-first programming concepts of extreme programming, begun in 1999, but more recently has created more general interest in its own right.

 

Just move on.

 

 

[Stefan Glienke 2002]

As a guideline: try to remove overhead from prologues and epilogues caused by variables of managed types (explicit or implicit) such as strings or interfaces that are only there for the uncommon path.

Another example was the error raising code in the hextobin thread that can be put into a subroutine that gets called only when the rase case of a invalid char occurs.

 

Eric Grange wrote a nice article about this some years ago that I like to recommend: https://www.delphitools.info/2009/05/06/code-optimization-go-for-the-jugular/

[David Heffernan 2345]

7 hours ago, Mike Torrettinni said:

During routine profiling I noticed a function that gets called 1mio+ times and I wanted to look into it, even though it's only 0.24% of total execution time. So, not a bottleneck, but still wanted to see is there anything need to be addressed.

 

Here is example that imitates a real function:

 

var flag: boolean = true;

function ProcessString(const aStr: string): string;
var s: string;
    i: integer;
    b: boolean;
begin
  if flag then
    Exit(aStr);
  
  // dummy code to use the local variables
  s := aStr;
  i := Length(s);
  b := i = 1;
  if b then
    Result := aStr
  else
    Result := s;
end;

As this function will always return string and exit, the same does my real function in 99.9% cases -  in only 0.01% cases executes the lower part of the function.

 

If I split functions to this:

function ProcessStringOLD(const aStr: string): string;
var s: string;
    i: integer;
    b: boolean;
begin
  s := aStr;
  i := Length(s);
  b := i = 1;
  if b then
    Result := aStr
  else
    Result := s;
end;

function ProcessStringNew(const aStr: string): string;
begin
  if flag then
    Exit(aStr)
  else
    Result := ProcessStringOLD(aStr);
end;

In this case, the new ProcessStringNew is 25% faster, because it never executes ProcessStringOLD - make sense.

 

But if I set the flag = false, then of course ProcessStringNew is slower vs original ProcessString, but only by 7%.

 

So new changes result in: 25% faster in 99.9% and 7% slower in 0.01%.

 

Does this micro optimization makes sense? I assume a few little changes like this across in multiple functions, and it could save some valuable execution time, >1%.

Is this code a bottleneck in your program? If not write it in the way that is easiest to read. How many times have I said that to you? Why would you choose to make your code hard to read for no benefit? 

[Bill Meyer 337]

28 minutes ago, David Heffernan said:

Is this code a bottleneck in your program? If not write it in the way that is easiest to read. How many times have I said that to you? Why would you choose to make your code hard to read for no benefit? 

Or as a friend advised me when I started learning to code, on my wood-burning CPU: First make it work, then worry about performance.