-1

Does adding a variable assignment (for the purpose of enhancing the Debugging process) to the following type of method slow down execution by more than a second (1k ms) over ~1k calls?

Am I correct in my assumption that the variable will fall out of scope and be garbage collected when the method completes execution?

Refactoring this method:

public String concatenateOneOrTwo(String input, boolean one){
    if(one){
        return concatenate(input, "one");
    }else{
        return concatenate(input, "two");
    }
}

To something like this:

public String concatenateOneOrTwo(String input, boolean one){
    String returnValue = "";

    if(one){
        returnValue = concatenate(input, "one");
    }else{
        returnValue = concatenate(input, "two");
    }

    return returnValue;
}

This minor refactor could improve the debugging process; This would allow the developer to easily inspect the return value and enhance the maintainability of the code.

Additional Resources

public String concatenate(String one, String two){
    return one + two;
}
Blake Yarbrough
  • 2,286
  • 1
  • 20
  • 36
  • 2
    The 2nd version is preferred, for readability, and I doubt you could measure the difference with any tools available to you. – EdgeCase Feb 11 '16 at 14:22
  • What's the problem evaluate in debugger value of entire `concatenateOneOrTwo` method? – Andremoniy Feb 11 '16 at 14:22
  • Simply compiling the two versions with javac shows that they do produce different bytecodes, with the second looking like it's slightly less efficient. I'd be stunned if it had any noticeable performance impact though. – resueman Feb 11 '16 at 14:27
  • @Andremoniy When debugging methods returned in a chain you have to follow the chain all the way down or all the way up to see the resulting value(s). By assigning the result to a variable before returning, you can see the value held at each point in the change where an evaluation is being performed. – Blake Yarbrough Feb 11 '16 at 14:28
  • Decent debugging tools will allow you to inspect the value without setting it to a local variable. – Manu Feb 11 '16 at 14:30
  • BTW Using `one.concat(two)` for two Strings will make far more difference. – Peter Lawrey Feb 11 '16 at 14:34
  • @Andremoniy In general, the method call changes the state of the object. Evaluating value of such method from the debugger will change the behaviour of the code. – Grogi Feb 11 '16 at 14:43

1 Answers1

2

I think it's fair to say that any performance cost associated with that variable declaration and assignment would be completely negligible.

When you call the concatenate method, the value returned is a reference to the actual string data. The string data itself is held on the heap. This happens in either of the scenarios you listed.

The variable returnValue is just a reference to the string; it is not a copy of the string, so it's memory footprint is very low. Additionally, returnVariable is stored on the stack, so it doesn't even need to be garbage collected. As soon as it goes out of scope, it is popped off the stack.

Either way, the bulk of the complexity (both time- and space- wise) happens either way due to the string concatenation (and storage of the string on the heap). So bottom line, that's probably not a cost you should be worried about.

tyler
  • 91
  • 5
  • Java stores only primitives on the stack. String ain't a primitive - it is created on the heap. To be precise, one could guess it is actually created inside the `concatenate` method. – Grogi Feb 11 '16 at 14:41
  • It's correct that strings are objects, so they are stored on the heap. The reference to the object, though is stored on the stack. So if the concat method call creates the string `"onetwo"`, `"onetwo"` is stored on the heap. `returnValue` is not the string, though. It is a reference to the string. That reference is stored on the stack. [This post](https://stackoverflow.com/questions/19623563/where-does-java-reference-variable-stored) discusses the concept in a bit more detail. – tyler Feb 11 '16 at 14:54