Re: [ANN] Lua 5.3.0 (work2) now available (number coercion holy crusade)

[Coroutines <coroutines@...>]

On Thu, Mar 27, 2014 at 1:30 AM, Oliver Kroth <oliver.kroth@nec-i.de> wrote:
> It would use one single buffer, possibly with precomputed sufficient size
> (if, e.g. all operands are strings).
> The .. operators use a buffer each plus the memory for the (intermediate)
> result strings.
> So string.concat() could save memory allocation operations and the multiple
> copy operations from one buffer into the next.
>
> At least this is my understanding, correct me if I am wrong...
>
> -- Oliver
>
> Am 27.03.2014 00:26, schrieb Luiz Henrique de Figueiredo:
>>>
>>> Why not create such a function as a member of the string library?
>>> string.concat( "there ", "I", " would look ",1, "st")
>>
>> How is that different from just this?
>>         "there " .. "I" .. " would look ",1 .. "st"
>>
>
>

I don't know within what sort of structure Lua strings eventually wind
up (where is the hash stored?) but this is the luaL_Buffer structure:
http://www.lua.org/source/5.2/lauxlib.h.html#luaL_Buffer

I kind of wish another member were added for referencing a string
after this one.  So when you concatenate strings (especially long
strings) they instead form a linked list that can be walked invisibly
later, rather than actually moving the strings together in memory.
The hash would be recomputed from the starting segment to include all
segments it can iterate to (the string in total).  If intermediate
string segments become unreferenced (collectable) they then get
realloc'd together with the nearest segment before that is still
reachable/referenced during a GC collection (for little gain though --
all you'd be doing away with is the "header" of the string structure.

If the 'next' ptr is NULL the string ends at that segment, if not you
continue forward.  A linked list of Lua strings has the potential to
contain many smaller, intermediate strings and avoid moving strings in
memory.

~ food for thought ? ~