WoW:Lua object memory sizes

Lua contains a fairly small set of data structures. This page aims to document how much size each structure uses, to aid addon programmers with memory optimization.

This data is from WoW 2.0, Lua 5.1

Strings

Strings are allocated and garbage collected by the lua engine. Equal strings will not take up extra space (all strings are stored by reference). When a new string is allocated in memory, it will consume AT LEAST (17 + string length) bytes. However, strings are also tracked in a global hash table, which will grow as necessary, making the average memory consumption somewhere around 24+length bytes when the number of globally tracked strings grows.

Tables

Tables behave in different ways depending on how much data is put in them, and the style of indexing used.

A new, empty table will consume 40 bytes.

As indexes are added, the table will allocate space for new indexes at an exponential rate. For example:

local t = {}  -- 40 bytes
t[1] = true   -- alloc 1 index
t[2] = true   -- alloc 1 index
t[3] = true   -- alloc 2 indexes
t[4] = true
t[5] = true   -- alloc 4 indexes
...

If a table is indexed by sequential integers, each index will take 16 bytes (not including any memory allocated for the value). If the becomes a hash, the index size will jump to 40 bytes each. Lua is "smart" and will allocate at the 16 byte rate as much as it can. If the int sequence is broken, the new values will allocate at the 40 byte rate. For example:

local t = {}  -- 40 bytes
t[1] = true   -- 16 bytes
t[2] = true   -- 16 bytes
t[3] = true   -- 32 bytes
t[4] = true
t[8] = true   -- 40 bytes
t[9] = true   -- 40 bytes
t[10] = true  -- 80 bytes
t["x"] = true
t["y"] = true -- 160 bytes
...

Note that sequential-int and hash allocation can be intermixed. Lua will continue to allocate at the 16-byte rate as long as it possibly can.

local t = {}  -- 40 bytes
t[1] = true   -- 16 bytes
t["1"] = true -- 40 bytes
t[2] = true   -- 16 bytes
t["2"] = true -- 40 bytes
t[3] = true   -- 32 bytes
t["3"] = true -- 80 bytes

Erasing values from a table will not deallocate space used for indexes. Thus, tables don't "shrink back" when erased. However, if a value is written into the table on a new index, the table will deallocate back to fit it's new data. This is not delayed until a GC step, but rather an immediate effect. To erase and shrink a table, one can use:

for i,v in pairs(t) do t[i] = nil end
t.reset = 1
t.reset = nil

It should be noted that erasing a table is generally more expensive than collecting the table during GC. One may wish to simply allocate a new empty table.

Function closures

Note that the actual code also uses RAM, of course. But that only happens once. Closures however are created each time the word "function" is executed.

Each function closure takes 20 bytes of RAM. The below code will use 20000 bytes:

for t=1,1000
  x = function() end
end

Upvalues that do not change only uses 4 bytes per closure. The below code will use 20000 + 4000 = 24000 bytes:

local semistatic = "hi!"
for t=1,1000
  x = function() print(semistatic) end
end

However, upvalues that actually change use an additional 32 bytes. The below code will use 20000 + 4000 + 32000 = 56000 bytes:

for t=1,1000
  x = function() print(t) end
end

And finally, a mix: The below code will use 20*2*500 + 4*2*500 + 32*500 = 40000 bytes

for t=1,500
  for i=1,2
    x = function() print(t) end
  end
end

Quiz!

To motivate programmers, here follows a number of statements. Only one is correct. If you choose the right one, you will be shown boobies (NSFW).

• It is better to have lots of named keys in a table rather than create a sub-table with integer indices
• It usually uses less CPU power to let the incremental GC handle tables compared to recycling them
• It is always better to use lots of upvalues to a function closure because locals don't use any memory