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

[Coroutines <coroutines@...>]

On Thu, Mar 27, 2014 at 12:42 PM, Javier Guerra Giraldez
<javier@guerrag.com> wrote:
> On Thu, Mar 27, 2014 at 2:10 PM, Coroutines <coroutines@gmail.com> wrote:
>> A linked list of Lua strings has the potential to
>> contain many smaller, intermediate strings and avoid moving strings in
>> memory.
>
>
> these are called 'ropes'
> http://en.wikipedia.org/wiki/Rope_(data_structure)  and have
> well-known advantages over simple strings, but most of them are easy
> to get just by using a Lua array of strings.  insertion/deletion is
> O(n), but here 'n' is the number of elements, which shouldn't be too
> big.
>
> usually, functions that build complex strings do it by populating an
> array and string.concat()'ing it at the end.  sometimes you can get by
> simply by skipping that last operation.
>
> i don't quite get your paragraph about GC'ing rope elements, if the
> rope isn't collectable, an element isn't either.  if elements are
> shared, then they're collectable once they cease to belong to any
> rope, just like common strings.
>
> --
> Javier
>

About the GC part: I meant that if you have a string segment like {
"cat", "dog", "horse" } and "dog" goes unreferenced/collectable, you
could realloc "cat" and then move "dog" into the actual string buffer
of "cat" to make { "catdog", "horse" } during an idle GC
operation/collection.  Though maybe it's a bad idea to allocate during
a proclaimed "collection" :p  I did now about ropes, but I didn't
think they were similar because the total length of the string across
its segments isn't tracked, just the hash of the total string.

Anyway, another person pointed out that this wouldn't be too good for
cache misses.  I have to agree that it would only be good to
"list"/sequence strings together when they are very long string
concatenations.