[berkut]

Hmm, a friend of mine from Criterion said that in two of the last games they did, they had to re-write the Lua parts (fairly significant) in C++ to get the framerate high enough as it's memory fragmentation was just too much.

They went from ~34 fps to ~60 fps for 4 developer weeks re-writing the Lua code.

[beagle3]

Ask them if they were using LuaJIT2; they probably didn't -- it's relatively new (only been stable enough for real work for less than a year).

It is ludicrously fast. It usually loses to optimized C / C++, but by no more than 10-20% -- and you have essentially no restrictions whatsoever on the Lua features you use; Furthermore, it's FFI makes interoperating with C / C++ a superfast breeze, dropping the FFI overhead to zero.

And even ignoring LuaJIT2 -- they probably took less time and got higher quality overall by going through Lua (assuming programmers were equally versed in Lua and C++, and the infrastructure was reasonable) -- it's easier to iterate and debug with Lua than it is with C++.

[SomeCallMeTim]

LuaJIT2 is awesome, but it still uses the Lua 5.1.4 garbage collector, so if the problem was GC related (i.e., memory fragmentation), then LuaJIT2 wouldn't help much.

OTOH, changing how you do things in Lua CAN be a big help in not generating garbage. I love the ability to ignore memory allocation in Lua, and I'm annoyed that I have to deal with thinking about it, but at least it's pretty straightforward.

Also, depending on the game, you can nuke your Lua allocation every level/section/other segment, allocating Lua memory from a memory pool. That can also help a lot with fragmentation.

But if you're doing a game that's one continuous experience, you have no choice but to be careful with managing memory. Again, it CAN be done from within Lua (think object pools), and that could be easier than porting to C++. And with LuaJIT 2, it would likely be fast enough in that case.