lua-users home
lua-l archive

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

2010/1/12 Daniel Wallin <>
Daniel thank for the comments yet some of your claims have flaws.
liam mail wrote:
> See
> current speed comparisons with swig 1.3.40
> and Luabind 9.0
             ^^^ that's luabind 0.9.
I am sorry for this typo it was late when I wrote the email, yet I assume there will be no confusion on which version of luabind is actually being used.
Since you are making such a fuss over this I'm going to comment on your

Well OOLua was designed with speed as a consideration. I did not realise that a single link was making a fuss yet showing off the it is quicker than other libraries tested.

First, it isn't very clear what you are trying to measure. For instance,
the first benchmark - "access" - is simply calling two member functions.
Why is it called "access"?

The first speed tests where against the hand written code from Game Programming Gems 6, if you look the code used and the test name is surprisingly similar.
local N = 10
local ave = 0

for i = 0, N do
    local h = Hero.Create(i)

    local t0 = os.clock()
    for i=1,1000000 do
        if h:GetEnergy()~=i then
    local dt = os.clock()-t0

    if i~=0 then
     ave = ave + dt


print('access (average elapsed time):',ave/N)

"virtual function" and "pure virtual
function" measure the exact same thing. Why?

That is a valid question yet one which I have already addressed on the wiki just above the following link
"The following test should give the same results per library, yet I wanted to check this."

But more importantly, *all* of your benchmarks are mixing in the cost of
fetching a member from an object. This is the primary reason your code
appears to perform better.

The reason is that normal usage (from my experience) is not to cache the function as it is an object orientated binding and given the fact that OOLua was designed not to have runtime overhead of function lookup (which I comment about in the following link and at other locations feel it is correct to test it like so. I could add the test you suggest, yet I am actually waiting for yourself to make the tests you have claimed in the past that luabind 0.8 was on par with swig. To my knowledge you have not made these public yet.

The reason lookups in OOLua is so fast is that __index doesn't call into
C++. Both Swig and luabind does, because they both support "properties".

I have never claimed that OOLua provides the same functionality as other binding libraries and have suggested that when someone is asking for a specifc piece of functionality that Luabind maybe a better alternative. After saying that I am a little unsure what you define as a property? Do you mean C++ side public member variables or Lua side? OOLua does not provide a method to store properties Lua side per instance yet does provide public member variable access via get and set methods, again implemented as function to not incur runtime lookup.

Further, there is essentially no error checking. For primitive types,
the error check consists of an assert(), so in the release build there
is no checking at all. For both Swig and luabind, calling a function
with the wrong parameter type will give a meaningful error, and at least
for primitive types there is no way of turning this off. For luabind at
least, this is by design.

This is true. OOLua assumes that you are passing the correct primitive types to functions which you call and there is only a check to see if the data is of the types which Lua provides using lua_isnumber et al in debug mode. Yet how do you check if an input is a char or int?

OOLua also doesn't verify that the userdata it gets from Lua is actually
a OOLua-wrapper. But to be fair, neither does Swig. I guess not doing
this might be OK if you can completely trust the Lua code that you run.
luabind 0.9 has no way of turning this check off, but my working copy
does (it's a one line change).

Actually it does. It first checks to see if the current type is the type requested and then travels the hierarchy to check if any of the base classes match the requested type.
If you make the lookup change as I outlined above to your benchmarks,
and make the error checking of userdata in luabind equal to that of
OOLua and Swig:

As stated I could make these changes yet am waiting for your test cases and it is valid to check the runtime lookup as it is part of the functionality provided.

I think you will get very different results. On my machine, this makes
OOLua slower than both luabind and Swig on every one of your benchmarks.

Interesting I will check this.
Daniel Wallin
BoostPro Computing