lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index] wrote:
> Drats, I'd never thought of that. I can see that would prevent it from
> being a
> useful patch to many people. Will have to keep an eye out of that in my
> own apping
> if I keep the mod #defd in. Thanks for the heads up.

Do be aware that stack relocation during execution of a CFunction
is fairly rare in practice, with the consequence that bugs may not
be visible during normal testing.

> Quick question about SpeedingUpStrings, how do you interpret the results?
> Am I
> reading it right that reusing a prestring gives you a 4x increase in large
> string writes?

I think that requires a lot more investigation. In principle, there is no
reason why a malloc of 20033 bytes should be any slower than a malloc of
53 bytes, but the benchmark seems to indicate otherwise. I suspect that
the time is related to a difference in the number of garbage collection
cycles which occur; however, the benchmark does not preload anything other
than the standard libraries, so the garbage collection frequency will not
correspond to a real program, in which the thresholds will be different.
It may well be that tuning the garbage collector may have produced
different results. A more scientific benchmark is definitely called for.

In any event, the reuse of prestrings is dangerous, as I note in the Wiki
page, since it is impossible to guarantee integrity with the standard
lua_lock() mechanism. In all but trivial applications, it is highly likely
that the string will be needed for something, and will therefore need to
be copied (or stringified); failure to do so will cause odd bugs (or

It could be that Lua could benefit from a formal StringBuffer type, but I
doubt whether it would be *significantly* faster than the naive
implementation with tables and table.concat. It is possible that the speed
of table.concat (and CFunctions which use the luaL_Buffer system in
general) could be improved by use of prestrings; I had that in mind as a
possible application of prestrings when I was writing it. One thing which
would demonstrably speed up algorithms like the standard "table of pieces"
StringBuffer would be the possibility to create a new table with a larger
initial array size.

I'm personally of the opinion that safety must not be compromised in the
quest for speed, and that simplicity is safer, all else being equal. Lua's
strings are remarkably efficient, and in part the various attempts to
"improve" them simply confirm that fact.