Re: Alternative C++ binding

[Mark Hamburg <mhamburg@...>]

One thing I've done instead of using luaL_newmetatable, etc. is to use
essentially identical code but with a light user data replacing the string
for the name. If you can count on there being exactly one instance of the
class name, I would presume that this would avoid the cost of the string
canonization on every pass through the API. (Another choice would be to
register the string and store a registry index. That works so long as you
only plan on having one Lua state and threads thereon in your application.)

One thing to watch out for in all of these bindings whether via luaL or an
equivalent such as I've just described is that if you build with something
like LuaThreads, you get a lot of traffic on the mutex which becomes a big
performance hit. My userdata intensive benchmarks suffered a much worse hit
for LuaThreads than did my benchmarks which stuck to straight Lua. (Even the
latter showed a noticeable degradation in performance, but not as dramatic.)

Then one can get into the issue that if you want to store references from
userdata objects to other Lua objects, the best way to do it appears to be
via the metatable for the object. Now you are into a custom metatable per
object which of course further adds to the cost of type-checking when you
come across the Lua boundary. (Sol's method tables look more and more
attractive.)

Don't, however, be tempted to forego the type-checking. I did recently and I
got burned by writing foo.method() instead of foo:method() and ending up
with a crashing bug.

Mark