Re: table.concat is inefficient for very long strings

[Francisco Olarte <folarte@...>]

On Thu, 21 Jul 2022 at 23:52, Gé Weijers <ge@weijers.org> wrote:
> I'd suggest growing the buffer by not doubling once you hit a certain threshold, but by growing the buffer by 20% or so, it will be slower but the behavior is still linear and the amount of unused space is lower.

I would sugest to never double, and use another ( <2 , potentially
varying ) factor. It is been pointed in many places, in a alloc-new,
copy, free-old scenario, disregarding things as block overheads,
growing by a factor >=2 insures you never reuse old memory, as the sum
of all previously allocated blocks is less than the new one. With a
smaller factor you can fit a new block in the old ones given some
conditions after a certain number of reallocations, i.e., with your
20% approach you can start with 1000, copy to 1200 after it on first
grow, copy to 1440 after both on second ( you only have the 1000 free
at this stage ), and on third growth spurt you can copy to 1728
allocated on the free 2200, and even colaesce the 472 at the tail with
the freed 1440 or deallocate all that if your memory allocator works
that way ( I know this is an oversimplification ). With a greater
factor, like 1.8, you need more cycles but eventually reach that
point.

Francisco Olarte.