[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: RE: Newbie Question - LuaBind and exec speed.
- From: "Nick Trout" <nick@...>
- Date: Fri, 25 Apr 2003 14:44:29 -0700
> How fast is the interface between lua and c++ via LuaBind? I'm not
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.
> 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).
You are asking all the right questions. Binding is not an exact science.
It is completely project dependent. Obviously scripting is not as
efficient in execution as native compiled code (possibly 20-30 times
slower). You have to ask yourself why are you using scripting? Perhaps
because it is more data driven development and allows you to express the
problem in a more friendly and concise manner. So you have to balance
out processing power, complexity of task to be completed, interface
complexity and development environment for behaviour developer, timeline
of project, potential for design change etc.
The traditional answer is develop in script and optimise into the
application, i.e. script driven. This solution can lead to your
application being biased toward the scripted solution so you have to be
careful who is designing and writing the scripts and driving
development. I think to have a framework in C++ which you bind to the
scripting (i.e. C++ driven) shows more thought on the core design side
earlier and can be more efficient (vague project designs will always
flounder whatever the solution). Restricting the binding to a minimum of
functionality may restrict large scale structural problems on the
scripting side but does not necessarily restrict behavioural programming
because the binding is focussed on the problem. This may also result in
greater efficiency since you are spending less time in script and the
binding. C++ driven development may also be better as you may develop
unit tests to make sure your system works as you would expect. You can
also code behaviour in C++ so you have the best of both worlds and can
layer your behaviour.
I take your point about the efficiency of the binding as it's
essentially lost time in runtime type checking etc. On a previous
project we got significant performance increases from turning off the
type checking in the release build once the debug version was happy
(this was using tolua). I would endeavour to balance development so that
the binding is kept to a minimum since it is dead weight. It can also
take up a significant amount of memory when larger if memory is
restricted.
Regards,
Nick