[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Another attempt at SpeedingUpStrings
- From: "Rici Lake" <lua@...>
- Date: Sat, 15 Dec 2007 19:26:17 -0000 (GMT)
> Hey all,
> I've noticed on the wiki a new article SpeedingUpStrings, which tackles
> improving loading strings through the C API.
Yes, I'd been meaning to post something to the list about that. Thanks
for mentioning it for me. :)
> I don't believe there's discussion pages on the wiki (unfortunately),
It's a wiki. Just edit the page and put in your commentary.
> ... I noticed that iterating
> over the characters in a string using string.sub required the whole string
> creation fiasco of hashing, copying, etc. It bothered my that a single
> character went through the same process as a multi megabyte string, so I
> aimed to improve this specific case by implementing a shortstr type.
Yes, Mike Pall and I tried an implementation of this some years ago.
However, there are several problems. The most serious is that it
breaks the promise of the Lua API, which is that the address of a
string as returned by lua_tolstring() remain constant while the string
is on the stack. The stack can be reallocated by lua_checkstack(), so
it is very difficult to maintain that guarantee. (Also, some extension
modules assume a strong guarantee, which is that the address of the
string remain constant while it is referenced from anywhere. This
guarantee is not made by the API, but it has historically worked.)
There probably would have been a way to deal with this but the test
implementation (which I believe is still available on the wiki) did
not indicate that there was much speedup. Basically, interning a new
string takes very little time, and there is some cost to the short
string implementation, most notably the fact that the hash needs
to be calculated on every use rather than being stored in the
string object; even using a fast hash algorithm, the slowdown
is noticeable. On some programs there was a speedup; on others
a slowdown, but on the whole the results were neutral.
In light of the problem mentioned above, we decided to abandon