lua-users home
lua-l archive

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


The question about performance of the various Lua-C binding mechanisms
is very interesing, and since I was thinking about it lately, I cannot
keep myself from posting my thoughts.

> How fast is the interface between lua and c++ via LuaBind? I'm not

You can find the answer to this question by running the benchmark
example in luabind. It measures the speed of a function call with 4
parameters using luabind vs. direct export. When I ran the test (in
release mode, without luabind type checking and string copying, i.e. the
fastest way), the luabind call was 2 times slower. However, the C
function bound thru luabind had its parameters already converted to C
variables, while the direct function should add 4 lua_totype calls to
convert the values from the stack. When I added those 4 calls, the ratio
dropped to 1.6 times.

> Basically, how much slower is it to update the properties of a c++
> class bound to a lua class than to just update a native lua class? I
> dont mean in exact cpu cycles or anything, im just wondering if the
> way im going about it is right (i will probably create a c++
> hierarchy and then mirror it into lua).

This is just the difference in function calls. It's more interesting to
see how fast are properties retrieved. But this cannot be so easily
measured, because there is no standard way of accessing C structure
fields from Lua, it depends which mechanism you are using (tolua, luna,
or your own). I haven't done such comparisons. I have done however
another thing - compared how much slower is accessing a C structure
field bound thru tolua than a direct table field access in Lua. I.e.,
when you write obj.name in Lua, what's the difference when "name" is a
simple Lua table field, accessed without a metamethod, or when it is
actually the "name" field of the C object pointed by "obj", and bound
thru tolua. The ratio is between 3 and 4.

When we used Lua for scripting in FreeGen ( our attempt to make a PC
first person shooter - http://gargagames.com/pcfg.php - which was
frozen, unfortunately ), we used our own binding mechanism in which
the C side was the "master", and the Lua side was the "slave". I.e., on
the C side object properties were accessed directly, and in Lua they
were accessed (both read and write) using stub functions. (Probably our
mechanism was slower than tolua, but that's another story). Our built-in
profiling showed that reading C object properties from Lua took a
serious and unacceptable percent of the time. On the other hand, setting
C object properties from Lua did not take so much time. Of course, this
depends on how often is an object property read, and how often it is
written to. I suppose this depends on the application (the game :), but
probably in most cases properties are more often read than written to.

So my conclusion was that the fastest way should be to have direct
property read access, and write access thru stubs. This means that you
should keep a copy of the C object as a table on the Lua side. When you
read a property from it, this should be a direct table access without
metamethod. When you write a property, you should have a "newindex"
metamethod which sets the property on the C side too. On the C side the
properties should be private, and should have Get/Set accessors (which
is actually the "correct" C++ style). In the Set accessors you should
set the values of the corresponding Lua table.

This is how I imagine things at the moment, though I may be wrong. For
example, it is possible that the way tolua binds C object properties to
Lua could be made faster, by storing the offset and type of each
property in a class-specific table, and use this info to speed up the
conversion. But I haven't tried that yet. Of course, one should always
remember Rule #1 of optimization - optimize only what counts, and find
out what needs to be optimized by profiling. So you should profile to
see what's the best solution in your case.

Unfortunately, none of the avaialable binding mechanisms uses the scheme
I described above, so I'll have to implement it myself (when I get to
that point). And it's a pity, because tolua and luabind are otherwise
great binding mechanisms, both with pluses and minuses. As I see them,
the pluses of luabind are type checking and ease of use (no additional
.pkg files), the minuses are slow compilation and probably slower
performance. On the other hand, the need to write .pkg files for tolua
may be considered a plus, not a minus, because they simply look more
readable than the binding code in luabind. However, you can never forget
to sync the luabind code with your C code and structures, because the
compiler will warn you (I haven't used tolua so I'm not sure if it has
any type checking, either at compile- or run-time).

> sure whether to implement my games class hierarchy in c++ and then
> bind those classes to Lua or whether i should implement the heirarchy
> entirely in lua and just call out to processor intensive c++ methods
> when i need to.

Definitely, having your class hierarchy entirely in Lua is much more
convenient and flexible. That's what Lua is all about...


Best Regards,

Ivan Kolev
Garga Games
www.gargagames.com