Change LUA 'Library'

[BraedonWooding]

So due to the amount of tests and performance tracking both me and @koosemose have performed its insanely clear that any performance drops is due to high GC on moon sharp's part, they just need to allocate too many objects which slows down on our performance, so I went searching since people wanted to keep LUA around.

I found SLUA, which seems perfect for our needs, it is a static binding library which means (yes you guessed it) 0 extra GC, and the performance stats are pretty damn good, the library uses a MIT license which is great for us. Other than that I wanted to create this issue just to see if anyone else knows of a more powerful library.

The big things that are required for us is;

• Low GC cost of Unity Objects (a small overhead is fine, but nothing near the level of MoonSharp)
• Efficient at calling C# functions (MoonSharp was good at this, and so is SLUA)
• Ability to interact with custom classes (an attribute would be nice)

[koosemose]

Main issue with slua is lack of documentation... or documentation in english anyways.

From what I can glean from looking at the examples, I'm not absolutely sure if we can interact with it the way we want/need to.

If you want to test it out and see if it can be used in a way that doesn't totally break our Lua interaction, feel free, having a working model makes it much easier to say if it will or won't work for us.

However, there are some things I think can be tried to improve Moonsharp's functionality, i just haven't had time to fully investigate them, due to limited time, and it not being a top-priority (since we're not released, "it works" is good enough for now).

[BraedonWooding]

Yep sure, I would say it's 'good' enough since in reality once its setup there should be no need for complex documentation (though in saying that I'll make some more documentation so that if changes need to occur there is something that is readable).

From what I could gather it would be insanely annoying to try to improve the GC, basically requiring us to restructure how we do things (they suggest using no/small objects which conflicts with most of how we do things and would add a lot more specific complexity to just LUA - and limit functionality).

I'll see how easy it is to implement, to the best of my knowledge looks just like a few button presses and an attribute or two :D.

[koosemose]

Well, there's the side of getting it so that we have it in the code base, and adapting our calls to work with theirs, and if we can actually continue to use it how we want to. Of course, not saying it can't, just that it may well be a lot of fumbling around to figure things out.

And also, we're quite a few versions behind on MoonSharp, quite a few of which involve improvements, so unless this turns out to work beautifully and problem free with minimal adaptation, I will likely delay any actual switch over until such time as I can investigate what else can be done with MoonSharp.

Or alternatively see if there's a different Lua library, I'm very wary of using a library which doesn't have documentation readable by most of our developers, and having to rely on documentation written by one of us.

[BraedonWooding]

Yes I agree, I just got it mostly working and just finalizing stuff, all the documentation actually comes with the application (it mostly exists inside unity editors, that guide you through).

[BraedonWooding]

Okay; so I've fixed up SLUA, it contained one or two small bugs that I fixed along with me fixing hundreds of function definitions. Some early testing indicates it works with no problems though I'm still working on getting it to a more tested state. It exists merely as a wrapper for LuaJit, and what it does better than MoonSharp is the fact that it has a code generator which generates stack based LUA code, effectively something like GetComponent becomes a quite long function which handles checking the types, creating pointers passing them to the C script which handles them, and pushing the values on the stack and off.

The code is all created automatically (well rather you press a button to indicate which code you want to generate from custom, to UnityEngine stuff), and you also have the ability to compile all the lua into bytecode (which we could do for our stuff to make it faster, so it doesn't have to compile it before it runs it and it can perform some more serious optimisations) along with the ability to put all the generated code into a dll (despite my attempts at getting formatting better in it, it still sometimes has a few spaces off, which while I'll iron out over time we really should push it into a dll, it also discourages editing).

So I haven't yet performed any bench marks and I only worked on it a bit tonight after not touching it for a few weeks, but based on the ones I've seen others do this looks like it will be significantly faster mainly due to the fact that we don't have to convert ANY objects to 'moonsharp' objects or anything like that, no boxing/unboxing, no GC collection will have to occur, very potent.

I did also want to supply a piece of code of some of the lua code that users would write (note that the whole beginning line is just basically like an import statement to make names shorter);

MonoBehaviour = UnityEngine.MonoBehaviour
GameObject = UnityEngine.MonoBehaviour

function main()
	local s,c = Custom.staticCustom();
	print(s,c)

	local a,b,x = c:instanceCustom()
	print(a,b,x)

	-- Type parameter can be pass in as string/type table
	print(c:getTypeName("UnityEngine.MonoBehaviour,UnityEngine"))
	print(c:getTypeName(MonoBehaviour))
	print(c:getTypeName(Custom))
	print(c:getTypeName(c:GetType()))

	-- Test getItem setItem
	print("---<"..c:getItem("test"))
	c:setItem("test",10)
	print("-->"..c:getItem("test"))
	c:setItem("test",100)
	print("-->"..c:getItem("test"))
end

The only annoyance I can see is the fact that it requires you to use : for accessing functions from 'objects' and . for variables (amongst a few other situations), this slight difference may trip up a few people and moonsharp fixed 99% of cases for you (though obviously that slowed it down a small bit).

Furthermore we would move the current modified SLUA project to OrderOfThePorcupine allowing others to fix things if problems occur (like if for some reason I fall off grid) and to allow it to grow and perhaps develop a community separate. Currently located here.

[dustinwloring1988]

I like this..
+1

[BraedonWooding]

I've started working on it again and I should have a more functional version soon.