What happens to a variable after it goes out of scope of a loop or a condition or a case?

Question

The reason for this question is just my curiosity to determine what could be the best practice on writing a high-performance stream consumer reading large size byte array from multiple channels. (although premature optimization is the root of all evil, this is more of a curiosity). I have read answers about similar senario specific to C here, but I am requesting answer specific to go, as it is a garbage collected language, and their documentation here says "From a correctness standpoint, you don't need to know where the variable is allocated".

If I have the following code to read from a channel,

    for {
    select {
    case msg := <-stream.Messages():
    ...snip...

Variable msg is within the scope of the case statement.

• What happens once it goes out of scope of case statement? Since this is declared in the same native function, and the size of stream could be a large byte slice, is the variable going to be stored in heap or stack, and if heap, will it be garbage collected, or does stack pointer comes into picture?
• Since this is inside an infinite for loop, and the size of stream is a large byte slice, is creating the variable and allocating memory every time an overhead,or should I declare the variable ahead, and keeps on over-writing it in every iteration, so that if there is a garbage collection involved, which I am not sure, I could possibly reduce the garbage?
• Shouldn't I be bothered about it at all?

Answer 1

Shouldn't I be bothered about it at all?

No.

(And once it bothers you: profile.)

Answer 2

If the channel value type is a slice, the value of the variable msg is just the slice descriptor, which is small (see https://blog.golang.org/go-slices-usage-and-internals). The array that contains the data the slice refers to will have been allocated elsewhere before the slice was placed on the channel. Assuming the value must survive after the function that allocated it returns, it will be on the heap. Note that the contents of the slice are not actually being moved or copied by the channel receive operation.

Once the value of msg becomes unreachable (by the variable going out of scope or being assigned a different value), assuming there are no other references to the array underlying the slice, it will be subject to garbage collection.

It's hard to say whether some amount of optimization would be helpful without knowing more about how the program works.