At what point does writing, maintaining and most importantly the overhead of a function become a viable alternative to repeated code?

Question

I've been wondering this for a while, and thought I'd pose the question today.

Example code:

private void createLinks(int numUsers) {
for (int i = 1; i <= numUsers; i++) {
    String userId = "ID-" + i;
    String randomId;
    // Generate an ID to link to.
    do {
        randomId = "ID-" + random.nextInt(i);
    } while (randomId.equals(iUserId));
    link(userId, randomId); //links the first argument to the second, 
                            //links are not bi-directional.

    // Generate 4 more ID's to link to.
    for (int j = 1; j <= 4; j++) {
        do {
            randomId = "ID-" + random.nextInt(i);
        } while (randomId.equals(iUserId));
        link(userId, randomId);
        link(randomId, userId);
    }

    // Generate another ID to link 
    do {
        randomId = "ID-" + random.nextInt(i);
    } while (randomId.equals(iUserId));
    link(randomId, userId)
  }
}

#createLinks is invoked a lot, and the do...while code snippet is being repeated in the method. Does it make sense to extract these 3 lines of code out to a method called generateRandomId(int i) and incur the function overhead to avoid this repetition? If createLinks gets invoked a 100 times, generateRandomId would get invoked 100*6 = 600 times.

This is more a language agnostic question rather than one specific to java, but it'd be interesting to know if some languages handle function overhead better than others. E.g. JVM does function inlining to optimize function calls, which might mean that a developer need not wonder about things that I mentioned above.

I don't worry about implementation performance of calling a function in any language, except *when* identified as a bottleneck - which is quite rare, inlining or not. It is the overall performance that matters and modern CPUs are very fast. 600 invocations is inconsequential here, especially in relation to overall work. — user2864740, Oct 06 '15 at 23:37

score 2 · Accepted Answer · answered Oct 07 '15 at 01:42

This is definitely opinion-based question, and I expect it will be closed. But I'll try to answer it anyway, because it's quite frequently asked.

If you want simple answer – don't bother about it. It's probably too soon. Really, the manner you ask a question tells me that you have a lack of information about how frequently this code will be called and how slow it really is. And it's ok. We all face this situation when there are just a lot of unknowns in the context of development. The trick is – those unknown will become knowns in operation context (when your code is actually running). You'll get a feedback about performance issues if any. It should be said, getting this feedback is not so simple task by itself and requires some skills and mature toolchain. But it's not the question you asked.

Does I advocate skip any performance optimization while developing? Of course no, it's silly. There are issues which could and should be solved early. I'm just advising to follow simple and straightforward principle:

If you're in doubt – wait for reality to show you the right way.

This principle could be misused as any other. But I hope you get my point – premature optimization is the root of all evil, right?

Good answer. I am going to do some profiling and find out for myself. — Siddhartha, Oct 07 '15 at 21:35

score 0 · Answer 2 · answered Oct 07 '15 at 02:09

My opinionated answer is "always." Whenever I find myself writing the same code twice, I make it a function.

The point where this practice ceases to be opinion-based is when two pieces of code doing exactly the same thing is important to the proper operation of the program.

At what point does writing, maintaining and most importantly the overhead of a function become a viable alternative to repeated code?

2 Answers2