[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: RE: string immutability
- From: Thijs Schreijer <thijs@...>
- Date: Thu, 2 Jan 2014 12:54:02 +0000
> -----Original Message-----
> From: lua-l-bounces@lists.lua.org [mailto:lua-l-bounces@lists.lua.org] On
> Behalf Of Enrico Colombini
> Sent: donderdag 2 januari 2014 10:29
> To: Lua mailing list
> Subject: Re: string immutability
>
> On 02/01/2014 9.57, Thijs Schreijer wrote:
> > local first = [[ some 100mb stuff here ]]
> > local second = first
> > local third = first .. "x"
>
> You have two strings here: 'first' and 'second' are the same string, 'third'
> is a different string.
>
That's the answer I was looking for. Thx.
> Assignment does not duplicate strings. Moreover, because strings are
> interned, there is a single copy of strings with equal contents; if you
> produce another identical string by different means (e.g. by concatenation),
> after the interning operation a single copy of the string will exist (please
> correct me if I am wrong here).
I don't know how it works in practice, but what you're suggesting means that after each string operation the resulting string would have to be compared to every other string in the current Lua state... I doubt whether that would be possible performance wise.
Considering the example again:
local first = [[ some 100mb stuff here ]]
local second = first
local third = first .. "" -- changed here, result is the same
My guess is it would still result in 2 strings, one being the value for `first` and `second`, the second one being the value for `third`, which would not be compared to the first because it is the result of an expression.
But maybe someone can enlighten us :)
Thijs
>
> ".." is a dangerous operator when doing many concatenations or when
> operating on large strings.
> table.concat and/or the C-level luaL_Buffer can be useful to reduce memory
> usage in these cases.
>
> --
> Enrico