Re: Performance (was Re: Selenophobia)

[Dirk Laurie <dirk.laurie@...>]

2017-03-25 22:48 GMT+02:00 Tim Hill <drtimhill@gmail.com>:

> 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.

The prime example of Lua C API coding is of course the Lua standard
library. Unfortunately we are conditioned by that fact to code in the same
way, which is why so many of us (I have also succumbed [1] to the
temptation) code nice applications that accept tables as arguments and
do tricky things perceived to be useful with them.

In my opinion things you code in C should be heavily appllication-oriented.
Two ways to do it.

  * Like Löve2D: the application is boss, one huge city of structures opaque
   to Lua and supplying a lua_State for the user to write callbacks in;
  * full userdata (even if all it does is to wrap one C pointer) with methods.
   A few  luaL_checkxxx's to get into pure C, stay there, a few lua_pushxxx's
   to give it back.

Actually the standard library is like both of those, except that the application
is itself represented by a lua_State. Every Lua chunk is just the body of
a callback, and all those API calls are merely methods of that special C city
called a lua_State.

[1] luarocks install xtable