Last post Jul 30, 2014 10:56 PM by motdotnet
Jul 30, 2014 07:04 PM|ftyper|LINK
Hello, cyclomatic complexity measures the number of logic branches in a method. Keeping cyclomatic complexity low helps produce code that is more structured and object-oriented. I've worked with some people in the past who did not know what cyclomatic complexity
was and did not have a very good understanding of object-oriented design. They argued that putting all of the code in a single method provided better performance.
I'm guessing that there may be some performance impact although I'm guessing that the impact is very minimal/insignificant. I wanted to present a typical standout scenario and get your feedback about the estimated performance impact from refactoring. Consider
a method with a cyclomatic complexity of 50. This method could be refactored into 10 separate methods, each with a cyclomatic complexity of 5 or less. Assume that any methods called in a loop won't be called more than 10 times/each.
Given this scenario, how much performance impact would you expect when refactored? My first impression is that performance would be impacted less than .1s but this only a guess. Based on your experience, past performance testing, etc, how much performance
impact would you expect in this refactoring scenario?
Jul 30, 2014 10:56 PM|motdotnet|LINK
In theory, the additional method invocations will consume processor time. Down at the bare metal the new method will need to be loaded to an address space and the execution pointer pointed to this new address. But with processors having clock frequencies
in GHz (and cache sizes in MBs), it will be silly to consider this factor (Unless you are coding a missile guidance/avoidance system or a controller for a nuclear reactor - in short if you have a requirement to save nanoseconds)
For this refactoring, in my opinion, the benefits easily outweigh the marginal overhead.