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.UPDATEA 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).
System Speed - Refactoring
software
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.