Introduction
Garbage collection of your system can cause performance problems if a large number of objects have been generated. This page discusses the issues involved and ideas for avoiding the problem.
Minimising objects created
Question: Basically I want to minimise the amount of temporary memory being allocated, so that I can reduce the frequency GC is called (and maybe reduce the hit of each GC?). Can anyone give some hints on this topic? For instance, if I have local variables declared inside function A, will the local variables allocate memory each time A is called?
(ET) No. Local variables are kept on a stack and will not affect the GC. These constructs will create a new garbage collected object:
-
a..b
(example only; any string generating construct i.e. strsub()
[*1] or lua_pushstring()
.)
- Each new string creates a new object. Lua has unique strings, that means that each possible string exists only once within Lua. If a new string occurs Lua first checks if it already exists within the string pool. If it does, a reference to that older string is used. If it does not exist, a new string object is created and put into the string pool. The GC checks the string pool for unused strings and frees them. So creating a lot of unique strings will trash the GC. I.e. this is bad GC-wise:
for i=1,100 do x="foo"..tostring(i) end -- 100 new strings
- Note: Code segments hold references to strings constants (a la "foo" above). So the string will exist in the string pool as long as the function exists; it does not have to be created each time the function is executed.
- Each time a table constructor is executed a new table is created. Try to reuse tables if possible. You could even go as far as creating and using newtable/freetable functions that manage a pool of unused tables. That way you get old style memory management for tables but you'll also get the old problems too ;-)
- Executing a function statement creates a closure (note: not calling the function but executing the function statement!). Normally no big impact on the GC but if you have function statements within a loop you may create a lot of garbage. I.e.:
for i=1,100 do foo(function() end) end -- bad for GC
- creates 100 function closures.
- Vararg functions create a table for the ellipsis (stored in '
arg
') each time the function is called. (Note: No longer true as of Lua 5.2, or if using LuaJIT.)
- In Lua 4.0 (and 3.x) userdata objects are handled similar to strings. They are equal if the pointer value and the tag are equal. What about Lua5?
- Well, these load/compile new code and will create strings and (GCed) code segments.
Freeing local variables
Question (continuation of above): So any local string or table will be freed when you exit a function?
Variables are a place to store objects (In fact, except for numbers it only holds pointers to the objects). Whether the stored object is a number or a table or anything else doesn't bother the variable. And local variables are not garbage collected objects themselves. So you may use them without creating intermediate objects. I think, that
was what the original poster meant.
- "So you may use them without creating intermediate objects." Does this need clarification? The variable itself doesnt create a GC object but its value could. You can use local variables which reference other existing objects without creating objects that need to be collected. But, you can't create new objects which are locals without creating an object that needs to be collected later.
About the objects stored within local variables: at the moment the local variable is no longer active the GC may collect the object that was stored there. The actual freeing of the object has nothing to do with function scopes or variable live times. The GC runs at certain times and frees all objects that are no longer accessible by any L
[*1] strsub
exists in Lua 4, not Lua 5.
RecentChanges · preferences
edit · history
Last edited April 18, 2014 6:12 pm GMT (diff)