A few months ago, we’ve released our new Lua implementation, Luau (Faster Lua VM Released) and made it the default for most platforms and configurations. Since then we’ve shipped many smaller changes that improved performance and expanded the usability of the VM. Many of them have been noted in release notes but some haven’t, so here’s a recap of everything that has happened in the Lua land since September!
When we launched the new VM, we did it without the full debugger support. The reason for this is that the new VM is substantially different and the old implementation of the debugger (that relied on line hooks) just doesn’t work.
We had to rebuild the low level implementation of the debugger from scratch - this is a tricky problem and it took time! We are excited to share a beta preview of this with you today.
To use this, simply make sure that you’re enrolled in the new Lua VM beta:
After this you can use the debugger as usual. If you see any bugs, please feel free to report them!
- The for loop optimization that specializes
ipairsnow works for localized versions of these globals as well, as well as
a^kexpressions are now faster for some trivial values of
- Calling methods and accessing properties on deeply nested Roblox objects is now significantly faster than it used to be (~2x faster for objects that have an 8-deep nesting) - the cost is now independent of the hierarchy depth.
- Accessing .X/.Y/.Z properties on Vector types is now ~30% faster
- On Windows and Xbox, we’ve tuned our interpreter to be ~5-6% faster on Lua-intensive code
- For a set of builtin functions, we now support very quickly calling them from VM via a new fastcall mechanism.
Fastcall requires the function call to be present in source as a global or localized global access (e.g. either
math.max(x, 1) or
max(x, 1) where
local max = math.max). This can be substantially faster than normal calls, e.g. this makes SHA256 benchmark ~1.7x faster. We are currently optimizing calls to
math libraries and additionally
type. Also, just like other global-based optimizations, this one is disabled if you use
Lua library extensions
We’ve implemented most library features available in later versions of upstream Lua, including:
table.unpackfrom Lua 5.2 (the latter is same as global
unpack, the former helps by storing the true argument count in
table.movefrom Lua 5.3 (useful for copying data between arrays)
coroutine.isyieldablefrom Lua 5.3
math.lognow accepts a second optional argument (as seen in Lua 5.2) for the logarithm base
We’ve also introduced two new functions in the
table.create(count, value)can create an array-like table quickly
table.find(table, value [, init])can quickly find the numeric index of the element in the table
Autocomplete support for
table.find will ship next week
Lua syntax extensions
We’ve started taking a look at improving the Lua syntax. To that end, we’ve incorporated a few changes from later versions of Lua into the literal syntax:
- String literals now support \z (skip whitespace), \x (hexadecimal byte) and \u (Unicode codepoint) escape sequences
and implemented a few extra changes:
- Number literals now support binary literals, e.g.
- Number literals now support underscores anywhere in the literal for easier digit grouping, e.g.
Note that the literal extensions aren’t currently supported in syntax highlighter in Studio but this will be amended soon.
Error messages are slowly getting a bit of love. We’ve improved some runtime errors to be nicer, in particular:
- When indexing operation fails, we now specify the key name or type, e.g. “attempt to index foo with ‘Health’”
- When arithmetic operations fails, we now specify the type of arithmetic operation, e.g. “attempt to perform arithmetic (add) on table and number”
We’ve also improved some parse errors to look nicer by providing extra context - for example, if you forget parentheses after function name in a function declaration, we will now say
Expected '(' when parsing function, got 'local'.
We are looking into some reports of misplaced line numbers on errors in multi-line expressions but this will only ship later.
There are always a few corner cases that we miss - a new Lua implementation is by necessity subtly different in a few places. Our goal is to find and correct as many of these issues as possible. In particular, we’ve:
- Fixed some cases where we wouldn’t preserve negative zero (
- Fixed cases where
getfenv(0)wouldn’t properly deoptimize access to builtin globals
- Fixed cases where calling a function with >255 parameters would overflow the stack
- Fixed errors with very very very long scripts and control flow around large blocks (thousands of lines of code in a single
- Fixed cases where in Studio on Windows, constant-time comparisons with NaNs didn’t behave properly (
Also, the upvalue limit in the new VM has been raised to 200 from 60; the limit in Lua 5.2 is 255 but we decided for now to match the local limit.
Along with the compiler and virtual machine, we’ve implemented a new linting framework on top of Luau which is similar to our old script analysis code but is richer. In particular, we support a few more checks that are enabled by default:
- Unreachable code warning, for cases where function provably doesn’t reach a specific point, such as redundant
returnafter a set of if/else statements where every branch returns or errors.
- Unknown type warning, which was emitted before for
IsAcalls, is now also emitted when the result of
typeofis compared to a string literal
- We now recognize and flag mistaken attempts to iterate downwards with a for loop (such as
for i=#t,1as well as cases where numeric for loop doesn’t reach the stated target (
- We now detect and flag cases where in assignment expressions variables are implicitly initialized with
nilor values are dropped during assignment
- “Statement spans multiple lines” warning now does not trigger on idiomatic constructs involving setting up locals in a block (
local name do ... name = value ... end)
We also have implemented a few more warnings for common style/correctness issues but they aren’t enabled yet - we’re looking into ways for us to enable them without too much user impact:
- Local variables that shadow other local variables / global variables
- Local variables that are assigned but never used
- Implicit returns, where functions that explicitly return values in some codepaths can reach the end of the function and implicitly return no values (which is error-prone)
There’s a fair bit of performance improvements that we haven’t gotten to yet that are on the roadmap - this includes general VM optimizations (faster function calls, faster conditional checks, faster error handling including pcall) and some library optimizations (in particular, Vector3 math performance improvements). And we’re starting to look into some exciting ways for us to make performance even better in the future.
Also we’re still working on the type system! It’s starting to take shape and we should have something ready for you by the end of the year, but you’ll learn about it in a separate post
As always don’t hesitate to reach out if you have any issues or have any suggestions for improvements.