This is why we felt comfortable saying that if the Lua version
of the application was running 50x slower than the C version, there
were probably issues in the Lua version's implementation that were
not good. The biggest problem was that the application had a loop
of the form
for i = 0 to a very big number
if flag==true
do stuff
else
do different stuff
end
end
the loop did not change flag. We recoded it as
if flag==true
for i = 0 to a very big number
do stuff
end
else
for i = 0 to a very big number
do different stuff
end
end
And got the 10x or so improvement in performance.
Any reasonable C computer would have optimized the C
code like this. Lua didn't.
I would never rely on a compiler to do this (though of course I’m aware they do). And I would certainly be concerned about any developer who did not understand how to code such a look efficiently, regardless of the aptitude of the compiler.
In our project, we avoided the “Lua is too slow” issue by providing a robust set of fast C libraries that did all the heavy lifting, leaving Lua to do business logic and decision making. I presented it as “C = muscle, Lua = brain”, which seemed to work out ok. However, developing that C library was not made easy by some of the design decisions in the Lua C API.
—Tim
|
