lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


In message <B14C9D7F1977D111AD740060970ACBDAD425AA@warhol>, "Vincent Penquerc'h
" writes:
> [drj@pobox.com writes]
> > Hmm.  Do you know that lua interns its strings?  What I mean 
> > is for any
> > particular sequence of characters that form a string lua keeps at most
> > one copy of that sequence in its heap.  So if I go:
> > 
> > lua_pushstring(L, "spong")
> > lua_pushstring(L, "spong")
> > 
> > there is only one copy of the string "spong" in the heap 
> > (there are two
> > objects both of which reference the same character sequence, 
> > but that's
> > unavoidable in any scheme).
> 
> When implementing a notification system, where events in a game
> engine end up generating calls to Lua scripts, it is common to
> use strings as parameters. These strings are only "active" in the
> Lua function called from C++ side, and are GC'd as the script
> returns. Such strings have a very low lifetime, and do not need
> to be otherwise "managed" by Lua. Moreover, the "interning" of
> strings by Lua mean that there will be (at least) a hash lookup
> whenever lua_pushstirng is called, which can add up when the
> script is just making simple boolean tests and return the value,
> which is rather common in my case.
> I am aware of course that I can take a reference to often used
> strings, and use this to speed it up.

Yes, there is still a hash overhead.  But without reimplementing the lua
VM you need to do that anyway.  When lua uses a string (to compare with
another string or look up in a table) it uses the pointer (ie, the hash)
not the sequence of characters.

When you say:

  These strings are only "active" in the Lua function called from
  C++ side, and are GC'd as the script returns. Such strings have a
  very low lifetime, and do not need to be otherwise "managed" by
  Lua.

I understand what you mean by the lifetime of the strings being very
low, but you say they are GC'ed as the script returns.  Do you mean that
you explicitly force a garbage collection when the script returns or do
you mean that you expect Lua to GC the strings when the script returns
(which it will not, it won't GC the strings until it decides to do a GC,
re pushing the string until then won't allocate any more memory)?

If you measured the overheads associated with strings to be too large
for your application then maybe numbers are the way to go.  You can still
use symbols to make it look nice in the source code, by doing
#define MegaOption 7
on the C++ side
and
MegaOption = 7
on the lua side

Cheers,
  drj