Question : Roadmap + stability

[G012481632]

1. I like what I read so far but am curious if there is a roadmap somewhere ?
2. How stable is version 0.50 (the dev version so far). Is it stable enough to start a professional project that will take about 2 years to build (and lua scripting plays an important role in it) or should i stick with NLua until a nearer 1.0 version of Lua-CSharp is available ?

Thanks and keep up the good work !

[Akeit0]

We will probably release version 0.5 in a little while, and then we will take feedback and make improvements for a while (a month maybe).
I think most of the API and specifications will be finalized there.
(Missing parts will be added after it.)

[Akeit0]

However, as for SourceGenerator, it needs a major overhaul.
#121

[G012481632]

Thanks @Akeit0 ! I have been testing both nlua and lua-csharp in a parallel setting (with akka.net) and using the exact same code and only a different actor (but the same implementation) holding either a nlua lua state or a lua-csharp luastate and using only a lua numeric variable 'x' changing every run and a (single) calculation ("return 10 + x*(1 + 1)") returning the result. I request 100_000_000 runs of the actor coordinated by the dispatcher actor handling the parallelism I set (I tested several values between 1 and 100 simultaneous running actors)(on a 16C/32T CPU)(one could do the same with Tasks, but had the testing for nlua already).

On average, nlua is around 20-30% faster in this type of scenario and that is not bad (nlua is fast) ! They both use about the same memory (a lot in gen2) since it is a lot of strings flying around. I compiled the nlua version for testing with bytecode and that resulted in 2/3 up to a 1/2 of the memory usage. The 0.5 (dev) of lua-csharp I have, the dump is not working (you where/are working on it, it seems), so I could not test it.

BTW, is it the same as with nlua for the 'dump' : run the 'loadstring(code)' and get the 'bytecode' (technically in lua/nlua a function unless you use the string.dump function of lua) or how should I use your implementation if it is not the case.

I did (so far) not test any functions or classes defined in c# and used in lua-csharp (or vise versa)(the source generator kicking in), but intend to do that, but prefer to have the dump when doing that (gen2 will grow very fast otherwise).
I suppose that in the official 0.5 version the sourcegenerator will do the job (be it not perfect as you mention, it needs a major overhaul) ?

Running larger scripts (with the cancellation option, nice nice ! - that nlua does not have !) is on my todo list as well.

I could even see me using both libraries together in one app and using the appropriate (akka) actor (either the nlua or the lua-csharp one) depending on the task ahead and the required speed/memory/cancellation specifics for that task.

Very nice work so far ! I like it a lot !

[CodeSmile-0000011110110111]

nlua is around 20-30% faster in this type of scenario and that is not bad (nlua is fast)

NLua is only fast(est) if you stay within Lua. Every time you pass the language barriers, NLua literally hits a wall. If you bind a C# method to NLua and call that method a million times, or vice versa call a Lua function a million times from C#, then this might be ten, a hundred or even a thousand times slower than LuaCSharp.

Do test this because if I understand correctly, you've so far only tested a for loop in Lua that changes a local variable. MoonSharp has always outperformed NLua in most common use-case scenarios where you do work with bound methods/functions because of the language barrier overhead.