Reminder to self: be aware of implicit setup/tear down code in methods
Posted by jpluimers on 2020/02/13
If a part of a method requires implicit setup/tear-down code (for instance when using managed types like arrays, strings, etc), especially in rarely taken execution paths, then consider putting that code in a separate method.
I bumped into this recently, and found out it does not just hold for Delphi, it can happen in other languages too.
A Delphi example I found back is this one: [WayBack] Delphi Corner Weblog: Speed problems caused by code that never ran.
The problem with Delphi is that the language does not have local scope (variables are at the start of the method) which means the penalty is for the full method.
I bumped into this in C# where a piece of legacy code had the variables declared away from the block where they finally were used.
This historically grew, because originally they were used in more placed of the code.
The refactoring limiting the scope just never put the declaration close to the usage hence violating the proximity principle.
Via: [WayBack] Ouch! Code that doesn’t get executed can still cause other code in the same procedure to become much slower. Of course, in retrospect, once you know the… – Thomas Mueller (dummzeuch) – Google+
–jeroen
The Wiert Corner - irregular stream of stuff 
Leave a comment