2

I'm too often facing situations where I need to get several types of information from a method. I usually think long and hard to circumvent these situations but I'm thinking it's pointless work that I'm doing. My question: should I prefer to take a slight performance hit in these situations, like iterating over an array twice for example (resulting in slower but cleaner code) or try to return everything at once with an instance of a custom helper class?

Here's a case example for the sake of it

char[] arr = {'a', 'b', 'a', 'c', 'a'};
int count = 0;  // 'a' and 'b' count
String word= "";  // 'a's and 'b's glued together in their occurring order
for (int i = 0; i < arr.length; ++i) {
    for (int j = 0; j <= arr[0].length; ++j) {
        if (arr[i][j] == 'a' || arr[i][j] == 'b') {
            ++count;
            word += Character.toString(arr[i][j]);
        }
    }
}
// return both 'count' and 'word' inside a new object or iterate twice?
Improve this question
13
  • 3
    This would be a better question with both "clear" and "fast" examples. Commented Oct 29, 2014 at 22:02
  • 1
    While your question hasn't been closed, you might find Why was my question closed as primarily opinion-based? useful. Commented Oct 29, 2014 at 22:03
  • 4
    Side bit, it always pains me to see someString += moreStuff; in Java. I've got a blog post on that - What goes on behind the scenes of += with String in Java Commented Oct 29, 2014 at 22:04
  • 2
    Actually, it would be better with a "real world" example (not to mention one that actually compiles). Especially because, in this case, count is simply word.length(). Commented Oct 29, 2014 at 22:06
  • 2
    Have you compiled this? It doesn't, you know. Maybe you want to eliminate the (for j...) loop? And you could just write return new String(arr).replaceAll("[^ab]", "")? Commented Oct 29, 2014 at 23:09

3 Answers 3

Reset to default
9

Premature Optimization is the root of all evil.

As Donald Knuth said,

Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.

Regardless of language, write your code to be as clear as you can. If looping twice really results in clearer code, go ahead and write that. A descent compiler may refactor away the second loop, or the overhead may be bottlenecked by other areas of your program. Unless your software is very widely used, it's likely that the time your successor spends trying to decipher a quick but complicated block of code will be more expensive than the fractionally increased runtime.

If, after testing, you find that a given program is running unacceptably slow, a refactor to the more complex means may be appropriate. But these situations are often difficult to identify in advance, because of this uncertainty more than anything else, you should err on the side of clarity over "performance" whenever such are in contention.

Improve this answer
7
  • I'm going ahead and accepting this one because of the "write first optimize later" principle you mentioned, and the Knuth quote. Sometimes I forget Commented Oct 29, 2014 at 22:16
  • 4
    I am surprised you brought out this old chestnut. You didn't even write the whole quote (it does matter), nor did you factor in sensible design decisions that should be made at the very beginning, like choosing the correct data structures having the appropriate performance characteristics for your particular programming task. That's not premature optimization; it's just sensible design. Writing slow code because you don't know simple performance optimizations that may actually enhance readability is not avoiding premature optimization; it's just a lack of education. Commented Oct 30, 2014 at 15:40
  • The question is about priorities, not the entire design process. (Although a specific question about "which is clearer, an object-method or multiple scalar-methods" would be interesting, as either Java or OOP specific.) Commented Oct 30, 2014 at 15:46
  • 2
    Then don't call it design. Call it "I pick the right data structures because I know what I'm doing." Call it "I write reasonably fast code from the beginning, because I know what I'm doing." Knuth's quote was always directed at the folks who don't understand what the 3 percent is (the part of the quote that you omitted), not the folks who are building adequate performance into their programs from the beginning, without using overly obtuse techniques. Commented Oct 30, 2014 at 15:49
  • 2
    c2.com/cgi/wiki?PrematureOptimization Commented Oct 30, 2014 at 16:19
10

The "premature optimisation is the root of all evil" thingy is nice and cute, but it is often misinterpreted and should not be used as an excuse to write poor code: if you can easily write code that obviously performs better, you should (for example by choosing the right data structure or avoiding to loop twice when one loop can do the job).

In the simple example you showed, you could create a class that handles the specific job. Something like:

class FindAGoodName {

    FindAGoodName(char[] array, char... retain letters) {
        //your loop here
    }

    int getCount() {}

    String getWord() {}

}

The code will be as readable (possibly more readable) and you only loop once. Everybody happy.

Improve this answer
4
  • 2
    "but, there's a lot of overhead in making a whole new class!" -- would say the novice upon hearing that premature optimization is overemphasized. :) Commented Oct 29, 2014 at 23:10
  • 3
    Yes, there is no justification for writing what I call deliberately inefficient code. [long rant omitted] Commented Oct 30, 2014 at 1:50
  • 2
    Classes do not necessarily have a lot of overhead. The question was about Java, which currently handles creating lots of little objects like this one very well. Commented Oct 30, 2014 at 19:06
  • Knuth's aphorism is one of the many good ideas that have been turned into mindless dogma by a segment of the developer community. I feel that software development attracts people who can only think in terms of dichotomies, and that if X is good, then total X must be perfection. Commented Apr 22, 2016 at 12:31
9

If the code change results in a...

  1. measurable performance improvement that
  2. satisfies a non-functional software requirement, and
  3. you cannot satisfy the requirement using simpler code

...then make the code change. Otherwise, you're almost always better off writing code that is easier to understand and more maintainable.

Improve this answer
3
  • 1
    Okay, so just common sense :) I was kind of expecting that Commented Oct 29, 2014 at 21:54
  • @WienerBoat Firstly common sense is not so common. But IMO Robert is saying more than that. Those three criteria actually impose quite strong constraints on what code changes we should make. Commented Oct 30, 2014 at 1:44
  • 1
    @WienerBoat as andy said, this is a lot stronger than 'common sense'. Condition 1 cannot be satisfied without actual performance measurements, taken before and after. More than once I've looked at code and gone.. "that has to be a bottleneck' only to later have the profiler tell me that some other thing completely the other side of the codebase is masking it completely. Commented Apr 22, 2016 at 1:50

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.