Re: Performance luabind vs. SWIG
Sebastian Wolff <[email protected]>
| Newsgroups | gmane.comp.lang.lua.bind.user |
|---|---|
| Message-ID | <[email protected]> |
Thanks for your reply, Daniel. I also could not imagine that luabind should be slower than SWIG. I still expect to improve in performance when more class methods are available and when the namespace itself becomes more crowded. For our team, we have to decide which wrapper tool must be chosen. I like the interface of Luabind very much, but it is outruled by the argument, that SWIG offers (almost) full automatic binding creation which is rather helpful. Therefore, the only arguments of Luabind would be either performance (As Bjorn Toft Madsen said, it would be good to see detailed benchmarks int the public) or features. Please do not understand my inquiry wrong, Luabind is a nice product, although we will probably stay with SWIG for the named reasons. Sebastian Zitat von Daniel Wallin <[email protected]>: > Sebastian Wolff wrote: >> This is quite astonishing since I thought that template magic may be >> able to speed up things. I did not use any special -D's, luabind was >> used as provided by my vendor (opensuse x64). >> >> I only wanted the list you know this. Maybe someone picks it up to >> finde some room for improvement in luabind. > > Things have improved a lot for 0.9. On my system, for your benchmark, I get: > > SWIG 7.3s > luabind 0.8.1 14.5s > luabind 0.9 10.5s > > I haven't looked to closely at the differences, but here are some things > that probably contributes: > > 1. luabind does more than SWIG when dispatching operators. SWIG > basically just stuffs a function directly in the metatable, luabind > has an extra level of indirection here. > > 2. luabind does more than SWIG when constructing an object. It mostly > comes from having a more complex object system. Doing: > > x = Someclass() > > will just drop right into the construction function in SWIG. With > luabind we get one, at least, extra level of indirection because > construction of the object holder is separated from initialization. > In theory, at least, we could complicate the implementation to > eliminate this when directly constructing an instance of a C++ > class. I'm inclined not though, because I want to keep the > implementation reasonably clean. > > Although this particular case shows quite a difference between luabind > and SWIG, I believe in general the differences are much smaller. I keep > my own benchmark suite, which shows luabind 0.9 being equal to SWIG in > most cases. > > -- > Daniel Wallin > BoostPro Computing > http://www.boostpro.com > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > luabind-user mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/luabind-user > ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july