Faster Lua VM Released

Our new Lua VM, Luau, is now, as of ~1h ago, live on all platforms for client and server for all games, and additionally live in Studio for plugins.

What is it?

As the platform grows, we see more and more use of Lua and as a result, it’s more and more important to make sure Lua scripts run efficiently. We’ve spent some time over the last few years optimizing our reflection layer - the system that allows Lua scripts to communicate to the engine - but we’ve never done anything about Lua itself.

With the goal of having Lua run faster on all our platforms, we’ve evaluated a set of approaches and decided to build a new Lua implementation because we’re crazy. We have written a brand new compiler and a brand new interpreter, and we’ve made a few changes to the reflection layer and garbage collector, but we haven’t changed the standard library, so depending on the performance characteristics of your code you will see varied gains. Reflection access got a bit faster in both old VM and new VM as a result of this work as well.

In usual scripts we see a mix of reflection access and other work - depending on what the scripts do you can get all the way between “it’s not faster at all” and “it’s several times faster” as a result. Our builtin terrain generator is about 2x faster with new VM, and some scripts we’ve looked at are up to 3x faster.

What about Studio?

We are not fully ready to switch to the new VM in Studio because we don’t have the debugger fully operational. However, the new VM has large performance improvements both in terms of code execution time, and in terms of join time (smaller bytecode => less data to send to the client during join => faster joins!). Additionally, it breaks many exploits because of the new bytecode structure but also because we no longer embed local variable names in the bytecode. (worth noting is that fundamentally the VM isn’t more secure aside from that and we expect exploiters to catch up)

These improvements are large enough that we decided to run the VM in contexts where the debugger isn’t necessary before we’re fully ready with the debugger support. If you want to run the new VM everywhere - which basically means “during testing in Studio” - and if you don’t use the debugger right now, you can use the Beta Features list in File menu to activate it:


We’re working on the debugger support and when it’s ready, we will automatically enable new VM in test modes in Studio as well, at which point the old VM will not exist on the platform anymore.

What’s next for Lua performance?

Due to the staged nature of our updates, we have three more performance improvements ready to go but waiting for mobile clients to catch up - in a few weeks time, calls to many builtin functions like math.abs, math.max, bit32.rshift et al will become substantially faster (we’re seeing ~2x performance improvement on an SHA256 benchmark for example), power operator (x^k) will become much faster for commonly uses powers such as 2 and 0.5, and reflection access to properties will become noticeably faster for objects with a long ancestry chain (e.g. we’re seeing ~2x faster reads of NumberValue.Value when NumberValue parent list has 8 instances in it).

Of course we want to keep improving the performance of our VM - if you have scripts that you’re not happy with performance of, feel free to share them with us which in some cases can lead to VM becoming faster. We already have a list of optimizations we want to implement, including closely integrated performant support for Vector3 math, improved performance for closure creation for non-mutable upvalues, better optimizations for table constructors and more.

We’re also looking into a way to unlock access to multiple cores. As I mentioned during my RDC talk (which you’re all welcome to watch!, we think we have a design that will allow you to run Lua code on multiple threads safely and performantly, which could unlock performance for some specific usecases that just isn’t achievable right now.


I’ve been waiting a long time for this now it’s finally here. Props to the team which made this amazing new vm.


Sweet! Thankfully will also make decompiling less readable to those who try to steal the games!


Always glad to see improvements!

Love this, adds abstraction to the code when decompiled, making it harder to read the decompiled code intuitively and the slowing down exploits is always good!


Faster join times, yeah!!


So, it’s only activated in game and in plugins. Does that mean you don’t specifically need to create scripts with the new Luau VM, that in-game they will always use the new VM? Therefore, this is the new replacement for the old Lua VM?

This is a great addition, I love hearing the slowing of exploits and the speed boost in games, as well as join time!


I’ve been waiting for this for sooooo long! I can enable a few flags on my game now to really take advantage of the perf boosts :slightly_smiling_face:


The new VM is one of the best improvements since the engine switch, but this actually got me super excited. Roblox is already at the point where it is a real threat to “AAA” engines when it comes to indie development, but managing to run a language like Lua on multiple threads in a relatively simple manner is something I haven’t really seen anywhere else and would really like to see this achieved.


I agree with @nooneisback, I’d like to hear more about this mystical multithreading. I’ve searched through your talk however I wasn’t able to find where you talked about it. Multithreading has historically been an issue for non-functional scripting languages since they are often OS / machine dependent and reverse many of the advantages of working in simple scripting languages.


Right now we have a design but not even a prototype so it’s too early to share details - when we get closer we will definitely have preview builds etc to make sure the concept is sane and sound.


I’m definitely excited for this! It’s a shame though that it’s a never ending full-on war with exploiters though. No matter what we throw they just throw something else back after a few weeks, or even less than that sometimes.

The performance boost I’m sure will also be greatly appreciated!


Next Up: 64 bit servers

That aside, this significantly improves the ability to make huge creations. I’ve noticed that a lot of stuff is 1.5-3 times faster, which is great for huge map calculations and any loop. Glad to see Roblox following the roadmap, I look forward to more!


Does this finally mean that my local scripts are safe from being decompiled by exploiters?


Short answer, no.

Longer answer:

Only temporarily, depending on how fast the exploiters adjust their decompilers. Even so, I would never use the word “safe” to describe anything exposed to the client.


Are there any plans for a general purpose vector/matrix computation library?


I am very excited to see it come, and LuaU is more of a way I’d say it as well, Luau sounds off, though this is a change, it won’t hold off the exploiters, they will simply just require time to update their scripts & injectors, though I am happy to see performance will be highly changed!

With that being said, I’m now working on a Battle Royal game, thanks to this update! :happy3:


This would be great for me personally, if it didn’t break what I used for my game (I run a personal script builder game for me and my friends). I replicate a localscript-like environment and I use __namecall for my fake objects (specifically my fake LocalPlayer instance). This has caused my converter to break, so I was wondering if we will ever get the name of the method passed into __namecall again.


Synapse is already compatible with the VM and they are already working on a decompiler for it. Don’t rely on this update for game security.


I’ve been hyped for the release of this as a scripter and someone who plays Phantom Forces on a sub-par CPU (irrelevant I know, I had to say this lol)

Very happy with the performance gains in my scripts!


Are there any practices that have been negatively impacted by this? Has anything gotten slower as a side effect? I understand that certain practices are no longer needed/fastest, but was anything slowed down?


As far as we know, there are practices that will make your code run slower than it can, but at the same speed as it used to on the old VM.