Re: Lua string library partially reimplemented in Lua

["David Manura" <dm.lua@...>]

On Wed, Sep 17, 2008 at 4:02 AM, Paul Moore wrote:
> Just out of curiosity, how does performance compare to the C versions?
> (I'm assuming it's slower, but how much penalty is there?)

A test of running pm.lua from the Lua 5.1 test suite (now on the wiki
page) shows about 500x slower.  PepperfishProfiler shows that most of
the time is spent in string indexing, as expected.

Almost no effort was made in optimizing, however; rather, it was a
straight port of lstrlib.c, and it wraps strings in a table interface
so as to behave like null-terminated C char arrays.  It's interesting
how the Lua and C code can be made structurally similar to a high
degree--even the C gotos in "match" are implemented in-place in terms
of Lua tail calls, pointers are transformed to indexes into arrays,
and I initially used zero-indexed arrays in Lua.

Note that not all of the string library can be reimplemented in Lua.
This notably includes string.sub, which I use to index the i-th
character of a string.  It might be more efficient to use string.byte
(which also can't be reimplemented in Lua).

On another point, I think it's inconsistent that Lua's VM has an
opcode to obtain the length in bytes of a string (i.e. # s), but
there's no opcode to obtain the i-th character or byte of a string
(e.g. s[i]).  This is because a check for string type is hardcoded
into the "len" event but not the "index" event[1].  Indexing a string
is a primitive operation on a primitive data type, so isn't that
worthy of an opcode rather than going through the standard library?
The presence of such an opcode might significantly improve the speed
of this and other things, as well as allow string.sub/string.byte
library functions to be implemented in Lua.

[1] http://www.lua.org/manual/5.1/manual.html#2.8