LuaJIT port

[Frityet]

Indexing large projects with a lot of dependencies can get quite slow, and with extremely large files autocomplete slows down. Is a port to LuaJIT possible/considered? I am considering making a PR to implement this

[CppCXY]

the to-be-close feature of Lua is very important for this project, luajit doesn't have this feature, so it can't be ported.

[Frityet]

the to-be-close feature of Lua is very important for this project, luajit doesn't have this feature, so it can't be ported.

ah! Thanks for letting me know, im gonna try and find ways around this...

[CppCXY]

I think it's almost impossible to implement, the project also uses a lot of language features from higher versions of lua, and the underlying C++ layer is actually bee.lua, which might be very difficult to replace with luajit.

Performance issues are often not what they seem, and it may be more appropriate to turn off some unnecessary features through some configuration.

[fesily]

You just need to make a lua5.4 to luajit bytecode front end to do it, huge amount of work

[Frityet]

You just need to make a lua5.4 to luajit bytecode front end to do it, huge amount of work

I was just going to replace where is with explicit calls, I grepped it and there was only like, 10 or so instances

[Frityet]

I think it's almost impossible to implement, the project also uses a lot of language features from higher versions of lua, and the underlying C++ layer is actually bee.lua, which might be very difficult to replace with luajit.

Performance issues are often not what they seem, and it may be more appropriate to turn off some unnecessary features through some configuration.

with compat53 and doing some modifications to bee.lua, it should be fine. The performance benifits of LuaJIT over lua 5.4 are so immense I would say its still worth it

[C3pa]

the to-be-close feature of Lua is very important for this project, luajit doesn't have this feature, so it can't be ported.

The inexistence of this feature doesn't mean that a port to LuaJIT isn't possible. It means that LuaJIT can't be used as a drop-in replacement for the standard Lua 5.4 interpreter. I am sure the LLS codebase can be ported to work with LuaJIT, but I can't give any estimations of the effort required to do so.

A friendly heads-up: Sumneko is doing a large rewrite of how LLS works. Turing-complete type system is in the making. For more info read here. So, I think it would be a good idea to wait with the LuaJIT port for the 4.0 version to land.

Edit: I had to look up what bee.lua is. I can't say how hard this port would be since bee.lua is more than the default Lua interpreter.

[fesily]

You first have to adapt the bee.lua library, and most importantly implement an escape library that implements the functionality, similar to webpack, to escape the js language version

[Frityet]

the to-be-close feature of Lua is very important for this project, luajit doesn't have this feature, so it can't be ported.

The inexistence of this feature doesn't mean that a port to LuaJIT isn't possible. It means that LuaJIT can't be used as a drop-in replacement for the standard Lua 5.4 interpreter. I am sure the LLS codebase can be ported to work with LuaJIT, but I can't give any estimations of the effort required to do so.

A friendly heads-up: Sumneko is doing a large rewrite of how LLS works. Turing-complete type system is in the making. For more info read here. So, I think it would be a good idea to wait with the LuaJIT port for the 4.0 version to land.

Edit: I had to look up what bee.lua is. I can't say how hard this port would be since bee.lua is more than the default Lua interpreter.

Thank you, this is a good point, adapting bee.lua shouldn't be hard either

[C3pa]

Thinking more about this, port to LuaJIT sounds like a nuclear option. If we take a step back and think about what motivates us to do this: we want better performance. So, I'd suggest first investigating if there is room for performance optimizations with the currently used Lua interpreter version. To do so, some profiling data is needed.

If you are really up to porting to LuaJIT, you might be interested to first try porting the LuaParser (https://github.com/LuaLS/LuaParser/tree/master) used by the LuaLS. If I am correct (someone with more knowledge of the functioning of LuaLS feel free to correct me), that is the component of LuaLS that is responsible for the most of time spent in this benchmark.

From a glance, the only used functions in LuaParser not available in Lua 5.1 I found are:

utf8.len
utf8.char
math.tointeger
math.maxinteger

This little experiment could be made more easily and if it shows significantly better parsing times in benchmarks, then it would make sense to proceed with the porting of other parts of LuaLS.

[Frityet]

Thinking more about this, port to LuaJIT sounds like a nuclear option. If we take a step back and think about what motivates us to do this: we want better performance. So, I'd suggest first investigating if there is room for performance optimizations with the currently used Lua interpreter version. To do so, some profiling data is needed.

If you are really up to porting to LuaJIT, you might be interested to first try porting the LuaParser (https://github.com/LuaLS/LuaParser/tree/master) used by the LuaLS. If I am correct (someone with more knowledge of the functioning of LuaLS feel free to correct me), that is the component of LuaLS that is responsible for the most of time spent in this benchmark.

From a glance, the only used functions in LuaParser not available in Lua 5.1 I found are:

utf8.len
utf8.char
math.tointeger
math.maxinteger

This little experiment could be made more easily and if it shows significantly better parsing times in benchmarks, then it would make sense to proceed with the porting of other parts of LuaLS.

Thats true, ill do some experimenting with that. Welp, time to embed LuaJIT into LuaLS I suppose