Memory Allocation for a Struct in golang

Akash Jain
4 min readApr 19, 2020

The user-defined data type is the most important quality of any programming language through which we can define our data type. Go is not being novel here. Lots of languages do that, so there are some important things I want to share. I am not gonna tell you what is a user-defined data type but I will explain how it manages in Go.

Let’s see the syntax of user-defined data type in Go.

type Employee struct {
ID int
Name string
Age int16
Gender string
Active bool
}

System defined type occupied some space in memory like below (Assume we are running on a 64-bit machine)

Now, what if I ask you the size of the Employee struct and then you simply add up of all data type used in that struct.

Employee struct size = 8(ID) + 16(Name) + 2(Age) + 16(Gender) + 1(Active) = 43 bytes

I will not say it’s a bad guess but as the old saying “Everything you see is not always the real”.

Run this program and you will find out

Size of main.Employee struct: 56 bytes

It’s shocking, right? But will explain to you why this happened and before going into this we need to understand what 64-bit machine is?

64-bit is a type of CPU architecture that is capable of transferring 64 bits of data per clock cycle. It is the amount of information that your CPU can process each time it operates.

Just to explain above architecture I wanna tell you one thing imagine you work in a supermarket and one time a truck comes to the store with lots of stuff and now you are the only one person who needs to unload that truck now you have to go to that truck and takes two bags from it with your bare hand and go to supermarket put that bag there and come back to the truck and do the same process again.

Similarly in 64-bit machine CPU takes 64 bit of data from memory and does the operation and sends back processed data back to memory and if the machine is 32-bit then it takes 32 bit of data from memory.

When we make data type it occupies memory in RAM sequentially as above Employee struct do as below

Memory Representation

CPU takes this data in chunks of 64 bits so, in the first cycle of CPU, it takes int (8)[ID] and half of the string (16)[Name], in the second cycle it takes half of the string (16)[Name] and int16 (2)[Age], in the third cycle, it takes half of the string (16)[Gender] and in the fourth cycle, it takes half of string (16)[Gender] in the fifth cycle, it takes bool (1)[Active]. It means reading string (16) will take two cycles of CPU so to save CPU cycle hardware uses alignment concept in which variable takes spaces in multiple data types. see below to understand

Here in the 4th cycle, it takes only 2 bytes but CPU could take 8 bytes (64 bit) but because of the alignment concept in 4th cycle 6 bytes memory will be wasted and similarly in the 7th cycle, it takes only 1 byte and 7 bytes will be wasted. It means a total of 13 bytes memory is of no use.

So if we add all memory (7 cycles * 64 = 448 bit = 56 bytes) you will find out why we got 56 bytes memory of employee struct.

Now there are very important things that you can notice here what if we combined the 4th and 7th cycle and make it one cycle then it will reduce the memory but how is it possible? Simply just rearrange your struct fields.

type Employee struct {
Name string
Gender string
ID int
Age int16
Active bool
}

Here we put fields in descending order of element’s memory size and now let’s execute the below script and see the size of employee struct, it’s shocking

Size of main.Employee struct: 48 bytes

No need to explain anything here just see below table and you will understand it by yourself.

Here we wasted only 5 bytes of memory so you just saw here ordering elements in struct makes memory allocation differently.

Conclusion: The best way to create a struct is to put all fields in descending order of data type size so that it reduces the cycle of CPU utilization and memory in RAM.

--

--

Akash Jain

Love to write code and discuss technology | If you explain to others in simple words it means you know it very well — akashjain132@gmail.com