Thread: Performance concerns regarding Lua integration

  1. #1
    Internet Superhero
    Join Date
    Sep 2006
    Location
    Denmark
    Posts
    964

    Performance concerns regarding Lua integration

    So i'm working on a 2D top-down space-shooter, and i've gotten to the part where all i need to do is integrate the logic for enemy movement and weapon upgrades etc.

    The way i was thinking about doing it, is to have a Lua script for each different kind of enemy defining how they move and how they shoot and so on, and then just calling that script everytime i update my entities.

    The thing is i might have alot of entities moving about on the screen, and the update happens once every frame for every entity, which in turn happens (hopefully) 60 times a second.

    My concern is that the Lua-code will slow my main gameloop down to a complete halt, i'm thinking Lua calls are fairly expensive to do a few thousand times a second. Is this something to be concerned about? I'm planning to use Luabind to export my C++ objects to the Lua scripts, but i don't want to implement it all just to find out i'm never going to get anywhere near an acceptable framerate.

    The other way i was thinking of doing it is to forget about Lua and then just use XML to define the behaviour of the different enemies and weapons and so on. At the moment i have a single config.xml file, which i load into a boost :: property_tree at the beginning, and then pass around by reference to each entity upon creation. This config file has everything from screen resolution to the width of the player ship and the clipping regions for the enemyships and so on. I was thinking about just hardcoding the different enemy behaviours and weapon types, and then just defining which enemies get which weapons and behaviours in my config.xml.

    Then if i ever wanted to define a new type of enemy for a new level, i could just combine the different components that i've got defined in C++, within the XML file, without ever having to recompile. This approach will be easier to implement, but less flexible, and i'm afraid the code will be a mess.

    Any advice?
    How I need a drink, alcoholic in nature, after the heavy lectures involving quantum mechanics.

  2. #2
    Registered User VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,607
    Lua is implemented under the hood in C and it is very fast. This is one reason so many current engines use Lua. As with anything some common sense optimization will help performance. I have called out to many objects in Lua with hardly any problem at all. Remember to keep your scripts lightweight and do the heavy lifting in C++. It sounds like you are linked into your update loop which is exactly where your Lua should execute. It has no business in the render side of things so wrapping your engine API for Lua in that regard would not be wise. That being said I am interested to know why you have thousands of non-static objects in your game world. Normally your static objects don't do anyhting and therefore do not need any scripting behind them. From what I can tell in your post your game architecture is sound. Why so many non-static objects?

    Also of note since Luabind is purely template based it will affect compilation performance not runtime performance. Luabind IMO is one of the best Lua binders available for C++.
    Last edited by VirtualAce; 03-27-2012 at 05:58 PM.

  3. #3
    Internet Superhero
    Join Date
    Sep 2006
    Location
    Denmark
    Posts
    964
    Quote Originally Posted by VirtualAce View Post
    Lua is implemented under the hood in C and it is very fast. This is one reason so many current engines use Lua. As with anything some common sense optimization will help performance. I have called out to many objects in Lua with hardly any problem at all. Remember to keep your scripts lightweight and do the heavy lifting in C++. It sounds like you are linked into your update loop which is exactly where your Lua should execute. It has no business in the render side of things so wrapping your engine API for Lua in that regard would not be wise. That being said I am interested to know why you have thousands of non-static objects in your game world. Normally your static objects don't do anyhting and therefore do not need any scripting behind them. From what I can tell in your post your game architecture is sound. Why so many non-static objects?

    Also of note since Luabind is purely template based it will affect compilation performance not runtime performance. Luabind IMO is one of the best Lua binders available for C++.
    Well, it wouldn't be totally unrealistic for me to have 100 enemyships on the screen at a time (although more than that wouldn't make any sense tbh), if i update these once per frame, and each of them needs to call a lua script, and i'm running at 60FPS then i'd be calling Lua functions 600 times a second. Add onto that the behaviour of asteroids or powerups and so on, i could imagine i could reach a thousand per second if i get creative ;-)

    Anyways, i appreciate the insight. I never planned to have the Lua do anything related to rendering, i have the rendering, collision detection and general entity-management set in stone in the C++ engine, that's where it'll stay.

    Edit: It's getting late and i have apparently completely forgotten how to multiply, disregard the numbers above, 100 x 60 is 6000 calls per second obviously.
    Last edited by Neo1; 03-27-2012 at 06:42 PM.
    How I need a drink, alcoholic in nature, after the heavy lectures involving quantum mechanics.

  4. #4
    Registered User
    Join Date
    Nov 2005
    Posts
    673
    I did this same thing with a project awhile back.
    My fix for the performance hit ended up requiring a rewrite of the way i was handling my ai.
    I made it so lua just "defined" these behaviors. Then the entities would just call their behavior from a list.
    I personally just gave each behavior a unique id that was used as the key in a map.
    I only had about 200ish behaviors so the overhead for the associative array wasnt enough to cause any issues.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. mingw32-g++ size concerns
    By Chris87 in forum C++ Programming
    Replies: 8
    Last Post: 07-30-2008, 03:04 PM
  2. any concerns with static memory in C?
    By caltiger in forum C Programming
    Replies: 6
    Last Post: 05-15-2008, 10:03 AM
  3. At My Wit's End (concerns passing char to constructor)
    By MisterWonderful in forum C++ Programming
    Replies: 1
    Last Post: 03-26-2004, 03:13 AM
  4. memory concerns
    By gustavosserra in forum C++ Programming
    Replies: 11
    Last Post: 05-21-2003, 09:29 PM
  5. speed/optimization concerns
    By confuted in forum C++ Programming
    Replies: 5
    Last Post: 04-01-2003, 12:29 AM