0

This is a question pertinent to languages that have garbage collection: example1:

public int CalculateSomething()
{
     //otherstuff
     int something = CalculateIt();
     return something;
}

vs example2:

public int CalculateSomething()
{
    //otherstuff
    return CalculateIt();
}

I want to name the variable so I can more easily see it in the debugger mode, but a colleague mentioned that it might not be wise to create a short lifespan variable. But I thought that's what the compiler did anyway?

Anyway, the question is: is doing it the first way (example1) in any way detrimental to garbage collection/performance? I'm using C# but am actually curious how Java and C++ behave in the same scenario as well.

rtgher
  • 149
  • 7
  • 1
    Your friend was likely confusing the fact that short lived *objects* can be difficult for some garbage collectors with variables. The only way variables would be problematic for the GC would be if the variable were actually long-lived and referred to the object longer than you actually need it (meaning the GC wouldn't collect it as soon as it otherwise could). Also: if the code in question really was about `int`s (and you didn't just change that to simplify the example), the GC has absolutely nothing to do with it. Ints are value types and thus aren't garbage collected. – sepp2k Nov 09 '18 at 15:48
  • @sepp2k `ints` are not universal in their representation. As this person is writing a compiler maybe you should qualify stacks/registers and objects, with the behavior of the target type system?. – Frank C. Nov 09 '18 at 15:54
  • 1
    It does not matter, the jitter optimizer has no trouble removing it again. This return value is returned through a processor register, one of the [most basic jobs](https://stackoverflow.com/a/4045073/17034) of the optimizer is replace local variables with registers. Feel free to use this style, it can make code easier to debug. C++ works the same way. Not so sure about Java but the hotspot jitter ought to get around to it. – Hans Passant Nov 09 '18 at 15:58
  • @FrankC. OP is clearly not writing a compiler, the question is mistagged (though I'm never quite sure how liberally to interpret the phrase "detailed inner workings" from the tag description). I was talking about C# because that's the language OP says they're using (though the same applies to Java). – sepp2k Nov 09 '18 at 15:59
  • @sepp2k Fair enough, the question is somewhat ambiguous and quite broad – Frank C. Nov 09 '18 at 16:00
  • @sepp2k no, the var in question was a complex object, I did simply the example, but I wanted a general answer anyway. Think I got it from the comments though. – rtgher Nov 09 '18 at 16:35

1 Answers1

1

With optimization on this should be an easy case for a compiler.

Stronger even, depending on the complexity of "otherstuff", there is a chance the whole method will be inlined.

Marco van de Voort
  • 25,628
  • 5
  • 56
  • 89
  • Wouldn't that depend on if this is a new language and what the backend strategy is? If this has a backend of, say, LLVM then you would certainly be spot on. – Frank C. Nov 09 '18 at 15:55
  • Anything remotely registering colouring and a simple concept of registerable variables will do. But even compilers that don't right now will certainly will be striving for such model in the long run, regardless of backends strategy. Apropos LLVM: I'm not a really big fan of it. Same sentiments about domination as GCC in the early 2000s, and the same faults; the needs of the premier frontends making the constant catch up of alternate frontends worse than the benefits in the long run. I guess in the ends LLVM will be just a C/C++ compiler and a few frontends that map 1:1 to those languages. – Marco van de Voort Nov 09 '18 at 18:32