WoW:Memory usage - Revision history

Move page script: Move page script moved page Memory usage to WoW:Memory usage without leaving a redirect

2023-08-15T04:48:52Z

Move page script moved page Memory usage to Memory usage without leaving a redirect

← Older revision

Revision as of 04:48, 15 August 2023

Bear at 21:54, 17 May 2020

2020-05-17T21:54:28Z

← Older revision		Revision as of 21:54, 17 May 2020
Line 1:		Line 1:
			{{merge\|Lua object memory sizes}}
	{{uitech}}		{{uitech}}
	~~{{merge\|Lua object memory sizes}}~~
	Information on the '''memory usage''' of data in the WoW [[Lua]] environment.		Information on the '''memory usage''' of data in the WoW [[Lua]] environment.

WoWWiki>Egingell at 07:39, 10 November 2009

2009-11-10T07:39:21Z

← Older revision		Revision as of 07:39, 10 November 2009
Line 4:		Line 4:

	== Data ==		== Data ==
	There are two basic classes of data that can be assigned to variables, passed around, etc, in ~~LUA~~.		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 ~~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.		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 ~~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.		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 ~~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:		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 ~~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.		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 ~~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.		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 ~~LUA~~ source code for details)		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 ==

WoWWiki>Laraul: /* Frames */

2008-12-17T23:09:55Z

Frames

← Older revision		Revision as of 23:09, 17 December 2008
Line 49:		Line 49:

	=== Frames ===		=== Frames ===
	Since a bulk of a frame's existence is on the 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.		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 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.		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.

WoWWiki>Tekkub at 03:29, 16 February 2008

2008-02-16T03:29:01Z

← Older revision		Revision as of 03:29, 16 February 2008
Line 1:		Line 1:
	{{uitech}}		{{uitech}}
			{{merge\|Lua object memory sizes}}
	Information on the '''memory usage''' of data in the WoW [[Lua]] environment.		Information on the '''memory usage''' of data in the WoW [[Lua]] environment.

WoWWiki>Hawkspur: minor spelling and grammatical corrections

2007-08-09T07:08:33Z

minor spelling and grammatical corrections

← Older revision		Revision as of 07:08, 9 August 2007
Line 23:		Line 23:
	* 'Map' entries - Those with non-consecutive integer indexes, and string indexes.- 40 bytes each		* 'Map' entries - Those with non-consecutive integer indexes, and string indexes.- 40 bytes each

	An empty table is just the minimum 32 bytes. As you start adding entries then it will begin to accumulate memory in which to store those. Memory accumulation isn't linear however, instead there is an ~~exponental~~ algorithm, so that as the table gets larger, incrementally larger numbers of elements are pre-allocated.		An empty table is just the minimum 32 bytes. As you start adding entries then it will begin to accumulate memory in which to store those. Memory accumulation isn't linear however, instead there is an exponential algorithm, so that as the table gets larger, incrementally larger numbers of elements are pre-allocated.

	For example, the size of a list of numbers increases as follows as new values are inserted: 36, 52, 68, 100, 100, 164, 164, 164, 164, etc..		For example, the size of a list of numbers increases as follows as new values are inserted: 36, 52, 68, 100, 100, 164, 164, 164, 164, etc..
Line 48:		Line 48:

	=== Frames ===		=== Frames ===
	Since a bulk of a frame's ~~existance~~ is on the 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.		Since a bulk of a frame's existence is on the 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 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.		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.

WoWWiki>Kirkburn: A little tidying

2007-08-09T06:29:50Z

A little tidying

← Older revision		Revision as of 06:29, 9 August 2007
Line 1:		Line 1:
	{{uitech}} ~~__NOTOC__~~		{{uitech}}
			Information on the '''memory usage''' of data in the WoW [[Lua]] environment.

	~~Some information~~ on the memory usage of data in the WoW ~~LUA~~ environment ~~(Expanding upon a forum posting)~~.

	== Data ==		== Data ==

WoWWiki>Flickering: /* Closures */

2007-08-09T06:10:35Z

Closures

← Older revision		Revision as of 06:10, 9 August 2007
Line 13:		Line 13:
	Complex data types (Userdata, Strings, and Tables) are represented as '''references''' to their actual value. Each reference fits in the same amount of memory as a value, but then the actual object that is referenced takes up additional space.		Complex data types (Userdata, Strings, and Tables) are represented as '''references''' to their actual value. Each reference fits in the same amount of memory as a value, but then the actual object that is referenced takes up additional space.

	==== Strings ====		=== Strings ===
	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.		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.

	==== Tables ====		=== Tables ===
	Unlike strings, tables can be altered, and may grow as entries are added to them. A table is made up of 3 parts:		Unlike strings, tables can be altered, and may grow as entries are added to them. A table is made up of 3 parts:

	* The table itself - 32 bytes		* The table itself - 36 bytes
	* 'List' entries - Those with consecutive integer indexes starting at 1 - 16 bytes each		* 'List' entries - Those with consecutive integer indexes starting at 1 - 16 bytes each
	* 'Map' entries - Those with non-consecutive integer indexes, and string indexes.- 80 bytes each		* 'Map' entries - Those with non-consecutive integer indexes, and string indexes.- 40 bytes each

	An empty table is just the minimum 32 bytes. As you start adding entries then it will begin to accumulate memory in which to store those. Memory accumulation isn't linear however, instead there is an exponental algorithm, so that as the table gets larger, incrementally larger numbers of elements are pre-allocated.		An empty table is just the minimum 32 bytes. As you start adding entries then it will begin to accumulate memory in which to store those. Memory accumulation isn't linear however, instead there is an exponental algorithm, so that as the table gets larger, incrementally larger numbers of elements are pre-allocated.

	For example, the size of a list of numbers increases as follows as new values are inserted: 32, 48, 64, 96, 96, ~~160~~, ~~160~~, ~~160~~, ~~160~~, etc..		For example, the size of a list of numbers increases as follows as new values are inserted: 36, 52, 68, 100, 100, 164, 164, 164, 164, etc..

	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 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 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
			* 4 bytes for each upvalue it references
			* 32 bytes for each distinct upvalue value

			This means that an arrangement like...

			function createClosures(a,b,c)
			return function() return 1,a,b,c end,
			function() return 2,a,b end
			end

			...allocates 172 bytes of memory every time it is run (28 bytes for each closure (56), 4 bytes for each of the upvalue references, three from the first closure, and two from the second (20), and 32 bytes for each of the three distinct upvalues (96))

			=== Frames ===
			Since a bulk of a frame's existance is on the 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 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)

	== 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 LUA source code for details)		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 ==

			In WoW 2.2, based on the PTR on 2007-08-08, the following functions can be used to determine the size of a dynamically allocated hash or array table:

			function DynamicHashTableSize(entries)
			if (entries == 0) then
			return 36;
			else
			return math.pow(2, math.ceil(math.log(entries) / math.log(2))) * 40 + 36;
			end
			end

			function DynamicArrayTableBytes(entries)
			return 36 + math.pow(2, math.ceil(math.log(entries) / math.log(2))) * 16
			end

WoWWiki>VoidvectorBot: Robot: converting/fixing HTML

2007-01-20T10:18:44Z

Robot: converting/fixing HTML

← Older revision		Revision as of 10:18, 20 January 2007
Line 8:		Line 8:

	=== Values ===		=== Values ===
	Simple data types like numbers and booleans are represented as their actual ~~<b>~~values~~</b>~~, and are passed around as such.		Simple data types like numbers and booleans are represented as their actual '''values''', and are passed around as such.

	=== References ===		=== References ===
	Complex data types (Userdata, Strings, and Tables) are represented as ~~<b>~~references~~</b>~~ to their actual value. Each reference fits in the same amount of memory as a value, but then the actual object that is referenced takes up additional space.		Complex data types (Userdata, Strings, and Tables) are represented as '''references''' to their actual value. Each reference fits in the same amount of memory as a value, but then the actual object that is referenced takes up additional space.

	==== Strings ====		==== Strings ====

WoWWiki>Hobinbot: demoted headings

2007-01-07T02:28:13Z

demoted headings

← Older revision		Revision as of 02:28, 7 January 2007
Line 4:		Line 4:
	Some information on the memory usage of data in the WoW LUA environment (Expanding upon a forum posting).		Some information on the memory usage of data in the WoW LUA environment (Expanding upon a forum posting).

	= Data =		== Data ==
	There are two basic classes of data that can be assigned to variables, passed around, etc, in LUA.		There are two basic classes of data that can be assigned to variables, passed around, etc, in LUA.

	== Values ==		=== Values ===
	Simple data types like numbers and booleans are represented as their actual <b>values</b>, and are passed around as such.		Simple data types like numbers and booleans are represented as their actual <b>values</b>, and are passed around as such.

	== References ==		=== References ===
	Complex data types (Userdata, Strings, and Tables) are represented as <b>references</b> to their actual value. Each reference fits in the same amount of memory as a value, but then the actual object that is referenced takes up additional space.		Complex data types (Userdata, Strings, and Tables) are represented as <b>references</b> to their actual value. Each reference fits in the same amount of memory as a value, but then the actual object that is referenced takes up additional space.

	=== Strings ===		==== Strings ====
	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.		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.

	=== Tables ===		==== Tables ====
	Unlike strings, tables can be altered, and may grow as entries are added to them. A table is made up of 3 parts:		Unlike strings, tables can be altered, and may grow as entries are added to them. A table is made up of 3 parts:

Line 31:		Line 31:
	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

	= 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 LUA source code for details)		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)