Last week I ran into serious speed problems with Lua/C++/Allegro5. Some of my game objects had to listen for triggers like DRAW and STEP 60 times a second. I implemented it in my C++ code as spawning a Lua thread for each triggered object. That means 120 threads are created/destroyed per second for a single object. When my instance count reached 300, game got really slow. The first optimization I made was that I brought all code from Lua step event into C++. I gained 20FPS. That however is a desperate solution.

Does anyone know why my approach is so slow and how can I reorganize my code to gain maximum speed while still using Lua?

Just to mention, I figured out that creation of a new coroutine is probably the reason of slowness so my current optimization ideas are:
1) Hold one lua thread open for each state so that in most cases when STEP or DRAW event occurs we already have a ready-to-use lua thread and we only create new threads when the old thread yields.
2) Bring Lua code into C++ for the objects that get great in numbers and are performance sensitive.
3) Make a separate "main loop" into a Lua Thread and only send events to it. So in turn that thread triggers the received events for subscribers without creating threads for them.

Generally my Lua/C++ architecture is like that:
*Main loop is in C++ where events occur. Objects are initially created in C++ as classes and finally destroyed there too. Each object has a unique id.
*Each object type has a lua state associated with it that can contain n number of lua threads for n objects at the same time.
*It is possible to call functions from some other *.lua file, but currently it creates a new lua thread for that. If that new thread should yield then the old thread won't wait for the return value and continues. I still have to figure out how to implement function calls into other *.lua files without spawning a new thread for that. I probably have to use 'require' but I'm not sure about the speed of this approach as eventually my lua code should be in memory instead of being loaded from the HDD.

I am building a system of Lua/C++ for the first couple of times so that I'm constantly not sure if professionals would do something in a different way.

I included a sample lua file from my project so you can see the architecture I am using as I invented it myself I cannot be sure if it's a right way to do things.

I agree with aniquilator. I haven't done much with Lua and haven't even touched it in a couple of years, but I infer the same from your solution. Having a new Lua state for each game object class is silly. Not only is it redundant and wasteful, but that probably also means that your game objects can't talk to different types without going indirectly through C++, into another Lua state, back into C++, and finally back into the original Lua state.

I'm not sure why calling functions from another Lua script would create threads unless you explicitly do this. As I said, it's been a while since I've used Lua, but I don't think it ever creates threads implicitly. I assume that it must be something that you are doing and I assume you are Doin' It Wrong(tm).

Apparently Lua doesn't actually have threads, unless that has changed in the past couple of years, so what kind of threads are you referring to? Apparently you should have a different Lua state for each native thread, which does more or less make sense, but that probably means that you don't want too many threads talking to Lua. In general, multi-threading adds a lot of complexity to a program and is therefore very error prone. Be sure you really need it before you use it. It could very well be that the complexity outweighs any benefits it may give you.

So limit your Lua states to one (unless you have a good reason not to, like multiple native threads that really do need to interact with Lua), limit the number of threads that you create (none if possible), and keep things simple.

Why would you need a different Lua state for each co-routine? That doesn't make any sense. No.

Each Lua script should be defining functionality. Basically functions. Once each script has been ran those functions should exist and should be callable. At least, AFAIK, that is how it would work. It doesn't matter that the functions are in different files. If they are declared globally then I think they should exist globally within the Lua environment until they are explicitly removed.

It sounds like you're trying to make C++ dynamically-typed. I don't really see the point of that. If you need performance for something then you'll need it in C++, but if you don't need performance then you might as well implement it in Lua. C++ can always manipulate the Lua environment so it will always be able to do everything that Lua can. Attempting to make C++ dynamically-typed will be sacrificing performance for flexibility. Make sure that's something that you really need. Again, you might consider going all the way into Lua in that case for simplicity's sake.

Yes.
And, as I understand it, in Lua you don't have such strict compilation-time checks as in C / C++ that can cause difficult organization of dependences:
If you use loadfile() or require() so that each file states which other will need to be loaded along, you have risk of forgetting one and you'll see the mistake only at runtime when an unknown function is called.

The alternative is to simply have your single Lua state load each module once. The order isn't even important!

You typically should not have multiple functions with the same name. A function name should describe what the function does. Conceptually, if two functions have the same name they should do exactly the same thing. You can use a table as a namespace to group functions around some other name, or you can use a table as an actual object (OOP) if that's is applicable.

What are these Lua objects holding? If the Lua objects represent the C++ objects then I would probably just wrap a userdata pointer to the object in a Lua table with some methods that call corresponding C++ methods. Otherwise, it sounds like you would be duplicating yourself, and that would mean that things could get out of sync easily... I don't really know what you're doing. You basically want the Lua world to see the C++ world as it is so you don't want to copy state from C++ into Lua. You want Lua to access the real C++ state through safe interfaces.

I don't know if I'm saying that or not. I would generally avoid too much global state, even in Lua. You may need one global variable to wrap everything else in, but that's all you technically need. That said, it might be beneficial to keep things simple to save effort, but if you have non-programmers writing the Lua then you may want to safely wrap everything up so they can't break the entire game with something silly.

If the list is global then probably, yes. Lua co-routines are not threads. They execute asynchronously, but the Lua API takes turns executing the code so it isn't faster to use or anything. If one of your functions blocks then all co-routines will be blocked also. I don't see any advantage to a lot of co-routine use until you're very familiar with Lua and know when it's appropriate to use them.

Lua has special syntax to make this easier:

id.update_position(id);

// ...is exactly the same as...

id:update_position();

This syntactic sugar just passes the table id into the function as the first argument (which is basically how all OO implementations that I've used actually work under the surface). That said, your name id doesn't seem appropriate if its a table... If it represents a duck then call it "duck", etc.

Note that there's no sense returning two values only to assign them back to the same table. Your function has a reference to that table already. Shouldn't you just directly assign to it inside of the function instead of returning anything?

I just went and read the Lua manual and it seems that Lua's run-time doesn't manage the execution of co-routines. You have to do that. Which means that you never have more than one "thread" in Lua running at a time. You have to explicitly yield your co-routine and then explicitly resume it. Meaning that if you create a ton of co-routines then you'll need to manage when to call which ones... And if they never yield then they aren't actually multitasking at all. They're just an extra expensive function call. Like I said, I think you're doing it wrong. You should probably check with the Lua community (e.g., IRC, mailing list, message board, whatever), but you probably shouldn't be using co-routines the way you are.

Get rid of the co-routines and see what happens. It could well be that you're expecting too much of Lua and need to move more of it into native code for speed. I would probably suggest that you have your main game loop in C++ and use it to invoke Lua when appropriate. But again, I'm not an expert on Lua, and have never actually embedded it before. This is just what I would probably do...

Instead of coroutines and yielding, you could make it event based. When a coroutine would yield now, it would request an action from the engine and return, then when the action completes/starts, the engine calls lua again to tell it what's happening. Could be a single function in lua that dispatches the events to other lua code, could be separate lua functions for each event.

I wouldn't put the main loop in lua. But I suppose that would work?

why even bother with threads? just call into the lua code from your C/C++ when needed?

AFAIK, userdata is effectively a C data type that Lua can't directly interact with. For example, it could be a pointer to your real object. Use C to generate a Lua table with a userdata attribute that contains your pointer. Then your Lua get/set methods could map to C++ functions that call a method of the class: extract the pointer from the userdata attribute of the table, extract the parameter to the Lua method, and then call the actual C function or C++ method on the object. Get the result and put that into Lua as a return value of the function. It will require a bit of coding to get it done, but it should about as fast as Lua can be and you won't have to worry about synchronizing Lua with C/C++. Lua will be pulling the values directly out of C/C++ instead. If you need even more speed after this, throw away your dynamic attributes in C++ and declare a static type. Then bind that into Lua so Lua can manipulate it directly.

How do you even manage 10000 coroutines? AFAICT, you are responsible for stopping and starting them every time... Are you sure they're all running?

I think you can consider a Lua state as effectively being a new VM instance. It would be like running a new JVM for every Java class or a new .NET runtime for every class. I guess the main difference is that Lua only runs when you explicitly call into the Lua library to run it, so they weren't all running at the same time (unless you used C or C++ threads to manage them)... But you were effectively maintaining a bunch of VM states...