-1
$\begingroup$

Could the runtime of methods within a system potentially be reduced via refactoring during development (pre-public release)?

i.e. Let's assume that methodX() takes 2 seconds to complete without having been refactored. It has been discovered that methodX() is suffering from severe code smells. After refactoring (for example, such as using global variables where appropriate or reducing the parameter list for methodX()), could methodX() potentially run faster (i.e. to 0.5 seconds, for example)?

Could the speed of the method potentially be increased if refactoring (i.e. eradication of code smells such as using global variables instead of creating x amount of individual variables, etc) has been applied?

Many thanks.

UPDATE

A few of you have provided some good answers, but unfortunately appear to be somewhat missing the point.

I am fully aware that the system's speed could be improved by changing the algorithm used; however, my question is not focussed on this and is more focussed on whether or not refactoring alone could potentially speed up the system (i.e. splitting up large methods/classes, reducing parameter lists, using static and/or global variables, addressing unreachable code (i.e. removing it altogether if it isn't serving a purpose or making it "reachable"), etc).

Improve this question
$\endgroup$
8
  • 1
    $\begingroup$ What makes you think this wouldn't be possible in general? $\endgroup$
    – James Custer
    May 2 '12 at 19:56
  • $\begingroup$ To vague at this point to be a good question. There are transformation of code that could reasonably be called "refactoring" that can help (fixing an out-of-order traversal of multi-dimensional array for instance), but that simply reflects the very broad scope of "refactoring". Be more specific. $\endgroup$
    – dmckee --- ex-moderator kitten
    May 2 '12 at 20:23
  • $\begingroup$ @James Custer Good question, but I never said that. If I thought that, then there wouldn't be much point in my question in the first place(!) $\endgroup$
    – SnookerFan
    May 2 '12 at 22:02
  • 1
    $\begingroup$ @SnookerFan I understand you didn't say it directly. However, the way I read your question is: "Suppose a method takes 2 seconds to complete without having been refactored. After refactoring, could the method run faster?" What's wrong with my interpretation? $\endgroup$
    – James Custer
    May 2 '12 at 22:09
  • 1
    $\begingroup$ At the moment it is not possible to see how this question is in the set of practical, answerable questions based on actual problems that you face, as required by this site. $\endgroup$
    – Mark Booth
    May 3 '12 at 12:04
3
$\begingroup$

In general, people refers to bad code, code smells, or whatever name you like, as code with low programmer productivity. I think we can agree that bad code is complex and difficult to maintain. Refactoring are just a guidelines to improve code quality from a human perspective.

Computer performance is a different issue, and in a nutshell is how much useful work is performed by a computer relative to its maximum capacity. Therefore, performance is not concerned about if a person can easily read the code, how easy is to maintain or extend the code.

So, can a messy code achieve higher performance than a readable, maintainable, and less complex code when both codes implement the same functionality or even the same algorithm? the answer depends on how well these codes map to the underlying architecture so that the generated programs are able to effectively and efficiently use the hardware.

For instance, consider that hand-tuned high-performance code (that tightly maps to the underlying hardware) is most commonly not easy to read, maintain, or extend... at all! If you are curious about this, you can look into the source code of the high-performance (until recently) GotoBLAS library and see how much it smells. The down side to hand-tuned high-performance code is that is not easy to read or maintain.

As Mike Dunlavey mentioned in a comment, for most software, good code and productivity are not necessarily opposite goals and code can be simultaneously improved in both directions. However, the closer you get to the maximum performance of the hardware (this is not the case for most software, hence the reference to high-performance GotoBLAS) the more important is the mapping from the expressions in the code to the the instructions that effectively run on the hardware. At this point you probably worry about hardware specific features that are hard to maintain and tune for, such as cache sizes, thread affinity, vector instructions, page faults, etc. I should add that good code practices make developing high-performance applications a much easier job, as you most likely need to maintain and extend such code.

The balance between programmer productivity and computer performance is one of the main struggles in high-performance scientific computing. There is a long list of initiatives to try solve this problem: advanced compilers, auto-tuning code, new programming languages, domain specific languages, programming patterns and guidelines, etc.

Improve this answer
$\endgroup$
3
  • $\begingroup$ It is a commonly-held anecdotal belief that there is an unavoidable trade-off between performance and maintainability. There's no science behind this. In my (anecdotal) experience, there may be such a trade-off curve, but most software is nowhere near the curve, and can be significantly improved in both directions. $\endgroup$
    – Mike Dunlavey
    May 3 '12 at 15:30
  • $\begingroup$ Hi Mike, I agree with you. Certainly most codes would benefit in performance and maintainability by following better design patterns, I was not arguing against that. However, the closer you get to the maximum performance of the hardware (hence the reference to high-performance GotoBLAS) the more important is the mapping from the expressions in the code to the the instructions that effectively run on the hardware. At this point you probably worry about hardware specific features that are hard to maintain and tune for such as cache sizes, thread affinity, vector instructions, page faults, etc. $\endgroup$
    – fcruz
    May 3 '12 at 16:07
  • $\begingroup$ I know what you mean. I find BLAS and LAPACK hard to follow even if they haven't been squeezed. There is a danger of just assuming they are highly optimized. A lot of those routines have character arguments that customize them, like upper versus lower triangle, etc. In our app at one point I found that a large fraction of time was going into simply checking those arguments. An ad-hoc routine was not only much faster, but much simpler as well. $\endgroup$
    – Mike Dunlavey
    May 3 '12 at 17:10
5
$\begingroup$

If by "refactoring" you mean just renaming things, breaking code out of one function and putting it into a different one, etc, then the answer is that the result is probably in the noise. There will be differences of course since the compiler compiles different code, but it's not going to be a lot.

You get significant speed improvements by changing the algorithm behind what you do. But that isn't usually called "refactoring".

In other words, it all depends what exactly it is you mean when you use the word "refactoring".

Improve this answer
$\endgroup$
3
$\begingroup$

Any refactoring you do will possibly affect the speed of the method, either making the method slower or faster. A lot of times refactoring is done by changing the actual algorithm used inside the method. Take as a simple example something learned in basic CS classes: sorting.

Suppose you have a method sort which takes in a list of things and outputs that same list, but sorted. You initially use a bubble sort, but later refactor the method to use a quicksort. Your method is now generally faster.

Improve this answer
$\endgroup$
1
$\begingroup$

If you have any concern about the speed of the software, then I would recommend concentrating on that first, as in this post.

Anything you do to improve speed is going to change the code, so it will look like refactoring.

Any changes you make to clean up the code might make it a little faster, and might make it a lot slower.

So by all means clean it up, but if performance is an issue (maybe it's not), make that your primary concern.

Improve this answer
$\endgroup$

Not the answer you're looking for? Browse other questions tagged or ask your own question.