|
What exactly is the problem here?If it's creating string constants at runtime, one could scan all strings (automatically, token-filters) used and pre-initialize them at the beginning of a chunk. Like:
local ___str_xxx= "xxx" ... if ____str_xxx then -- was if "xxx" thenThis would effectively pre-initialize the whole of alphabet etc. often used little strings. Not sure what bytecode Lua currently uses for such.
If the issue is about dynamically created strings, this would of course be unuseful. Personally, I have never faced problems with Lua strings, if one deals with them the recommended way, i.e. using 'table.concat' for long concatenations.
-asko Javier Guerra kirjoitti 17.12.2007 kello 19:43:
On 12/17/07, Mark Hamburg <mhamburg@adobe.com> wrote:But my concern on string speed has more to do with pushing table keys from C code. A relatively large amount of work goes into finding the matching existing string and this probably makes userdata less efficient than tables.Maybe short strings would help there as well.the solution i'd like to see is something more like how Lua code does it: string constants are interned at compile time and referenced by integer constants. but i think you'd end up with something like lua_ref(): runtime computed indexes (instead of C constants), and at least one extra table reference. is there a better way? -- Javier