Re: [ANN] Lua 5.2.1 (work1) now available

[Mike Pall <mikelu-1203@...>]

Coda Highland wrote:
> On Fri, Mar 23, 2012 at 12:08 PM, Mike Pall <mikelu-1203@mike.de> wrote:
> > There's even compelling evidence, including benchmarks, that
> > flattened, colocated strings (which is what Lua 5.1 uses) are the
> > best option: http://ssw.jku.at/Research/Papers/Haeubl08Master/
> 
> I respect your experience in optimization, but I have to wonder how
> your link even relates to the proposal at hand. The abstract looks
> fairly unrelated -- a discussion of how to handle metadata for strings
> with relationship to its content.

Well, it starts by explaining the deficiencies of the standard JVM
model for strings. That's a very basic variant of ropes with
shared string data plus offset and length in the metadata (the
string object itself). This allows fast substring operations etc.

The paper shows that even this simple variant of ropes is slower
than flat, colocated strings (which is what Lua 5.1 uses).

> No one here was promoting ropes as being the basic string
> implementation for Lua. It was being proposed specifically as an
> intermediate structure for the concatenation operator, to be flattened
> on demand when the object is needed in a string context (except for
> more concatenation, and possibly getting the length as it's a common
> enough idiom to append until a certain size is reached).

IMHO it's the job of a JIT compiler to create such an intermediate
structure, should the need arise. Neither the user should have to
deal with it, nor the VM as a whole. A simple growable buffer
looks like a better choice than ropes for that.

--Mike