Tracking memory allocation overhead in @time on mutable struct code

[xor0110]

I was making some experiments with the code mentioned in this StackOverflow thread In julia, why is the memory allocated the same, but the number of allocations vastly different? - Stack Overflow

It relates to this blog: Should I use mutable or immutable containers for agent based models in Julia? | juliabloggers.com

This discourse thread seems to be discussing the same issue, but I’m not entirely sure the conclusions there are correct

What is the memory overhead of a mutable struct?

The issue is the call setindex!(testers, MemTester(i), i), i.e. testers[i] = MemTester(i). The first argument is of unknown type (because it is a global variable), therefore julia needs to call into the runtime: It calls a C function that walks the method table and figures out whom to call. I think the issue is that this C function expects arguments that are pointers to valid heap-allocated julia objects and then extracts the argument types from their headers. We already have a pointer to MemTe…

My experiments show that code allocating immutable structs allocate exactly the amount of memory I expect. Eg a struct with one Int64 takes 8 bytes, 4 values take 32 bytes, and the vectors containing these objects take eg 32k for 1024 objects.

With mutable structs, @time reports more allocation than I’d expect. A vector of 1024 mutable objects will occupy 8k, consistent with a 64bit pointer, what I was expecting, as the vector holds references to the mutable objects. There should be also and extra 32k allocation, the same amount of memory taken by the immutable version. But then @time actually reports 56k. There seems to be an extra 16 bytes per object.

In other words, if I produce a vector of immutable objects that take 32 bytes, I get a 32k vector, and @time reports exactly that to me. If I create a vector of mutable objects, I was expecting 8k +32k=40k, but @time reports 56k, or an extra 16 bytes per object.

If the object has 3 Int64s, I get 40k when I’d expect 24k+8k, so and extra 8 bytes per object.

Where is this extra memory allocation happening? Is it actual memory being occupied somewhere, or is it just some artifact from @time’s computations? What causes it?