[important] How much memory will an int32 var actually consume?

Getting Help
4

Not enough information to conclude. You need disassemble it to check the status of stack/heap.

Taking that assumption that i is definitely declared on heap, i is still retaining its int32 data type nature, which is a valid int32 variable storing 3 as value. j however, holds the memory address of i instead.

Excluding j, yes. If j is initialized using j := &i, then j itself is a valid variable holding pointer value (32-bit memory in your case). If j is included, it should be 2 int32 data size, 2 32-bits pointers.

However, if j is initialized using:

var j interface{}
j = i

It is very hard to tell unless you disassemble it and analyze from there. interface{} is not an object and it has special meaning in Go. Long story short, you should not treat interface{} as a generic data type like the one in Java, although it behaves almost like one.

2 ways you can do it:

  1. You build a benchmark performance test to output specifically the memory performance.
  2. You use unsafe package to check it, on the run.

For such experimentation, I will use the latter option since it’s easier. Here is an example:

package main

import (
	"fmt"
	"unsafe"
)

func main() {
	i8 := int8(3)
	fmt.Printf("Type:%T | Address:%v | Pointer Size:%v | Mem Size:%v\n",
		i8,
		&i8,
		unsafe.Sizeof(&i8),
		unsafe.Sizeof(i8))

	i16 := int16(3)
	fmt.Printf("Type:%T | Address:%v | Pointer Size:%v | Mem Size:%v\n",
		i16,
		&i16,
		unsafe.Sizeof(&i16),
		unsafe.Sizeof(i16))

	i32 := int32(3)
	fmt.Printf("Type:%T | Address:%v | Pointer Size:%v | Mem Size:%v\n",
		i32,
		&i32,
		unsafe.Sizeof(&i32),
		unsafe.Sizeof(i32))

	i64 := int64(3)
	fmt.Printf("Type:%T | Address:%v | Pointer Size:%v | Mem Size:%v\n",
		i64,
		&i64,
		unsafe.Sizeof(&i64),
		unsafe.Sizeof(i64))

	i := int(3)
	fmt.Printf("Type:%T | Address:%v | Pointer Size:%v | Mem Size:%v\n",
		i,
		&i,
		unsafe.Sizeof(&i),
		unsafe.Sizeof(i))
}

// Output:
// Type:int8 | Address:0xc000096000 | Pointer Size:8 | Mem Size:1
// Type:int16 | Address:0xc000096020 | Pointer Size:8 | Mem Size:2
// Type:int32 | Address:0xc000096024 | Pointer Size:8 | Mem Size:4
// Type:int64 | Address:0xc000096030 | Pointer Size:8 | Mem Size:8
// Type:int | Address:0xc000014160 | Pointer Size:8 | Mem Size:8

It’s defined in your code, as in data- type declaration at variable creations. If you define the variable with a value, the default data-type for that value is used.

Strictly speaking, no. Data types should stop at compiler level except when you explicitly compile the binary with debugging symbols. It is only useful for human-side, not machine side.

No it makes no sense because not all programs use concurrency. In those situation, creating additional and unused data fields is a waste of resources.

Yes being the reason: you created either a mutex lock or a channel, assuming you’re referring to the Java’s extra lock field.

Take it as a grain of salt…

p/s: thanks for asking. :rofl: :see_no_evil:

Let’s amp it up a bit… :hear_no_evil::speak_no_evil:

  1. You have to Google on your side for read-up resources instead of asking others to do it for you. This helps you in your career by asking proper questions and exhibits some level of professionalism.

  2. You’re equipped with disassembler knowledge with your previous question. Do try them out on your side so you can trim down self-answerable questions like the one I mentioned above.

Do note that some powerful developers (of I worked before) exhibits weird and interesting social behavior. This statement is very offensive to them and some do hurl sharp fruit knife across the desk and detests you for life as if you cheated his/her +1. It will be life saving tip.

  1. I’m not sure are you aware that you’re either digging into the deep rabbit hole of unknown or a hole for yourself in this case. If you read through all the materials and its linked expansions asked in your other threads, you should realized by now, in Go, we do not need to manage stack/heap explicitly or manually unless you’re TinyGo developer, which the project is still developing the no-GC MMU. Your interviewer is likely look into something else that is not technical.
  1. I’m sorry to hear that you exhibited what we called “premature optimization”, if you understand my 3rd point.

Just these 4 points are good enough to show that you are not ready to be a real senior developer yet. Those are junior developers (of any languages) trait and attitudes. You might want to work on them.

Best wishes in your career advancement.

Reference

  1. go - How much memory is allocated for int8, int16 and int32 in Golang? - Stack Overflow
  2. unsafe package - unsafe - Go Packages
3 Likes