[prev in list] [next in list] [prev in thread] [next in thread] 

List:       lua-l
Subject:    Re: suggestion: table.remove and non-integer keys
From:       Ulrich Schmidt <u.sch.zw () gmx ! de>
Date:       2015-08-25 17:38:17
Message-ID: 55DCA809.10205 () gmx ! de
[Download RAW message or body]



Am 25.08.2015 um 19:33 schrieb Tim Hill:
> 
> > 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
> 
> 
Ok its clear now. Thanks a lot.

Ulrich.


[prev in list] [next in list] [prev in thread] [next in thread]