▲ | mabster 4 days ago | |
We were using Luajit with our own extensions with our own binding mechanisms that included automatic translation of indices. And we had A LOT of bindings. There was some "fun" there. Luajit C functions uses space indentation that becomes tabs every 8 spaces, i.e. mixed tabs and spaces. And his custom assembler for the assembly portions. I personally spent a lot of time "refactoring code to generate less garbage" as we had purposeful garbage collection in our idle time. One of the advantages with Lua was that everyone could code in it. I.e. for our games all the artists, sound engineers and producers were developing Lua which was super productive. But the function signature one in particular - that would have saved me a lot of stress on release nights! | ||
▲ | jhatemyjob 3 days ago | parent [-] | |
Oh wow you were editing the source of LuaJIT? That sounds like a nightmare. I'm pretty sure Mike Pall is the only person who understands that codebase lol. To be honest I am trying to move away from LuaJIT, now that q66's cffi-lua project exists I don't have a reason to use LuaJIT from a dev productivity perspective. For speed, sure. But for my use-case regular Lua is fast enough and the added features in 5.4 over 5.1 are really nice. Plus having the option to easily edit the Lua source code if I want gives me a lot of comfort, since the codebase is way simpler than LuaJIT's. I have removed LuaJIT from everything I use other than OpenResty. If I could, I would remove it from OpenResty but that is a huge undertaking Yeah the garbage collector is one of the things in Lua I really don't like - in Lua 5.4 Roberto added the <close> thing and generational GC but I'm not sure how well these work in practice. I guess I'm lucky enough in that I have never hit the upper limit where a GC cycle totally kills performance and if that ever happens I have the option of rewriting that code in C |