Hello! So I'm working from HK which means using the wife's laptop. What I discovered once getting Texas to compile for windows is that it doesn't run as quickly on her machine. Naturally, thought I, It's a graphics card related problem. Reason being, my Sempron 2800 CPU can't be faster than Core2 Duo, right?
Always remember that laptops are underpowered, flaky, and stupid.
I ran the profiler and it turned out that a lot of time was being spent in lua_pcall and the like, which meant that the lua code was sucking all the time. So it's not a graphics related slowdown, it has to do with the CPU. I downloaded LuaProfiler and figured out how to get it to work.
The trick with LuaProfiler is that a) it only gives you function names, which is a pity e.g., when you have a class heirarchy like classname:update (T) it will lump all the update () functions together and b) it doesn't give you a call graph. The call graph you can work around by searching your code and cross-referencing but separating out the lumped-together function names is a hassle. What I do is for each class's update (T) method, I peel it out into classname_update (T) and have classname:update(T) call self:classname_update (T). This is sort of labor intensive, adds a certain inefficiency on top of what's already there, but it works.
Anyhow what I've learned is that a great deal of time is spent in my lovely "sway" simulation code, for sound effects. Yeargh! This is a bummer, and I think the only real way to get it to work efficiently is to peel the code into C++. There is probably a workable hack but it doesn't feel right.
The question then, is what code should I peel into C++? I actually run sway simulations in a couple of places. Once for renderables (visible elements) and once for soundables (audible elements). However, the renderables are all in C++ and have appropriate glue to link them with lua. For soundables, I put them into straight lua and this it turns out is much nicer to work with because it lacks the glue. Only in the case of this sway simulation has it caused a problem, because whereas with the renderable the sway code is all C++ and runs instantly the lua equivalent is sucking up a lot of CPU time.
Option 1 would be to rip out the entirely soundable stuff from lua and make it C++. This is kind of an ugly option because of the amount of code it probably will end up touching. As well, it would be a lot of code to convert from lua to C++. The nice part is that it would solve the efficiency problem quite neatly, and probably give a meaningful efficiency gain for other parts of the code, as well.
Option 2 is to take an create a special "simulation" class hierarchy. So what I would have is an abstract "simulation" class where you'd be able to create different simulations (right now, I'd just have a swaying one) and then glue them into lua, e.g. with an abstract push_lua_state (L) function that creates a lua table on the stack to return. The sway soundable would then create a sway simulation and just read the appropriate parameters to determine if it needs to play a sound.
Option 2 on the surface seems clunky, but I think I will go with it. There are a couple of reasons. First, there are the problems inherent with Option 1 above. But second, Option 2 is actually more forward-looking.
What I'd like to have in the future is actually less C++ code with more general glue. That will probably necessitate some way to take code from lua and put it into C++ when there are real efficiency problems. Pursuing this pathway might help me to see what a good way to do this is, for future projects. There is the added benefit that I might need to move other lua code into C++ later on, and I'd then have a framework in place to do it.