Re: suggestion: table.remove and non-integer keys

[Tim Hill <drtimhill@...>]

> On Aug 25, 2015, at 8:41 AM, Ulrich Schmidt <u.sch.zw@gmx.de> wrote:
> 
> 
> 
> Am 25.08.2015 um 16:29 schrieb Patrick Donnelly:
>> On Tue, Aug 25, 2015 at 7:14 AM, Rena <hyperhacker@gmail.com> wrote:
>>> Lua strings are immutable (they can't be changed), so there should never be
>>> multiple copies of a string in one Lua state[1].
>>> [...]
>>> [1] for very short strings it might keep multiple copies when this would be
>>> more efficient than keeping references, but this is an implementation detail
>>> that we don't need to know about. :-)
>> You have it reversed. Lua may have multiple copies of large strings
>> but not short strings (len(s) <= 40):
>> 
>> http://www.lua.org/source/5.3/lstring.c.html#luaS_newlstr
>> 
> Ok now i am completely confused.
> After reading your linked source i am back at my starting point, asuming the only value assigned by reference is a table/list. All other are assinged by value. So a
> _stringvar1= stringvar2_ creates a copy of the source string.
> (still assuming we are talking about strings of size 1kB+ as in my program.)
> 
> Ulrich.
> 

To clarify…

Strings are immutable. When you “copy” a string in Lua, you merely copy a reference to that existing string, so the overhead in both speed and size is small and (nearly) constant. You can easily try this for yourself with a simple Lua programs that makes lots of copies of a big string into (say) a Lua array. This cheap copy also applies to passing strings as arguments, so you also get low-cost function calls when using long string arguments.

When you create a NEW string (for example, by concatenating two existing strings), then Lua does indeed need to make a copy of the actual string data to create that new string. However, for stings below a certain size threshold, Lua attempts to “intern” the newly created string. That is, it checks to see if an existing identical string already exists, and, if it does, replaces that newly created string with another reference to the (already interned) string. The threshold for this interning process is set at compile time, and by default is 40 bytes. The rational here is that the probability of two big strings being the same rapidly diminishes as size increases, so at a certain threshold the space savings is offset by the extra overhead of the interning process. Again, you can demonstrate this for yourself; try creating an array using a loop that concatenates two strings repeatedly; if the new string is below the threshold, Lua will intern it and you will see very little memory overhead. if the string is above the threshold, Lua will consume additional memory for each new copy.

HTH

—Tim