m
no edit summary
m (→Frames) |
mNo edit summary |
||
| Line 4: | Line 4: | ||
== Data == | == Data == | ||
There are two basic classes of data that can be assigned to variables, passed around, etc, in | There are two basic classes of data that can be assigned to variables, passed around, etc, in Lua. | ||
=== Values === | === Values === | ||
| Line 13: | Line 13: | ||
=== Strings === | === Strings === | ||
The contents of strings are immutable, so once created a string cannot be changed, just replaced with another string. This allows | The contents of strings are immutable, so once created a string cannot be changed, just replaced with another string. This allows Lua to maintain a pool of every distinct string value in use, such that multiple occurrences of the same string are all in fact references to the same unchangeable string object. | ||
If you have a table containing 30,000 entries of "Visit http://www.wowwiki.com/ to find out how to get more out of the World of Warcraft", there's actually only one instance of the text itself. Each occurrence of the string is a reference to that shared instance. | If you have a table containing 30,000 entries of "Visit http://www.wowwiki.com/ to find out how to get more out of the World of Warcraft", there's actually only one instance of the text itself. Each occurrence of the string is a reference to that shared instance. | ||
| Line 30: | Line 30: | ||
Tables which mix both forms of values (list entries, and map entries) use a mix of the two entry types | Tables which mix both forms of values (list entries, and map entries) use a mix of the two entry types | ||
In | In Lua 5.1 tables that are created with literal initializers such as x = { "a", "b", key = "value" } allocate exactly what they need without any extra pre-allocation. | ||
=== Closures === | === Closures === | ||
Closures are the manifestation of function prototypes within the | Closures are the manifestation of function prototypes within the Lua environment. Lua closures consist of a base object, with some storage for each upvalue the closure references, and then there's allocated space for each upvalue itself. In WoW 2.2.0 (Measured on the PTR on 2007-08-08) the memory usage for each is as follows: | ||
* 28 bytes for the base closure | * 28 bytes for the base closure | ||
| Line 49: | Line 49: | ||
=== Frames === | === Frames === | ||
Since a bulk of a frame's existence is on the C/C++ side of things, it's a bit difficult to get a true sense of their memory impact, however it's possible to measure the | Since a bulk of a frame's existence is on the C/C++ side of things, it's a bit difficult to get a true sense of their memory impact, however it's possible to measure the Lua footprint of the frame alone. It turns out that a frame's Lua footprint is initially just the size of its table representation (76 bytes, in WoW 2.2), there doesn't appear to be any other "magic" internal repository of other data. | ||
Having said that, it's a little tricky to fully test this because many of | Having said that, it's a little tricky to fully test this because many of Lua's internal structures (The global environment, the Lua string table, the internal C library reference table) are dynamically managed and grow with the exponential algorithm mentioned earlier, so it's possible that there's some table entries there being consumed by the frames. | ||
Most puzzling (and the largest reason I suspect there is a hidden internal data structure somewhere) is that there doesn't appear to be a readily measurable impact of :SetScript on a frame, yet the frame seems to manage to keep a reference to its handler quite happily. I'm guessing that each non-nil script handler really consumes about 16 bytes in the form of an entry in the library's reference table, but I could be entirely wrong! - [[User:Flickering|Flickering]] 06:10, 9 August 2007 (UTC) | Most puzzling (and the largest reason I suspect there is a hidden internal data structure somewhere) is that there doesn't appear to be a readily measurable impact of :SetScript on a frame, yet the frame seems to manage to keep a reference to its handler quite happily. I'm guessing that each non-nil script handler really consumes about 16 bytes in the form of an entry in the library's reference table, but I could be entirely wrong! - [[User:Flickering|Flickering]] 06:10, 9 August 2007 (UTC) | ||
| Line 57: | Line 57: | ||
== Local Variables == | == Local Variables == | ||
Locally scoped variables in functions are stored on the stack, rather than being part of the garbage collected memory heap, however if the variable contains a reference type, then the actual data referenced is not on the stack. (Though it's not actually a stack, per se, see the | Locally scoped variables in functions are stored on the stack, rather than being part of the garbage collected memory heap, however if the variable contains a reference type, then the actual data referenced is not on the stack. (Though it's not actually a stack, per se, see the Lua source code for details) | ||
== Reference Functions == | == Reference Functions == | ||