Luau Recap: September 2021

[PysephDEV (Pyseph)]

@FunnyOldWorld

We provide autocomplete suggestions for Player.PlayerGui .

This has been bothering me for god-knows-how long, I’m so glad it’s finally supported now! Great to see all the optimizations too - I found it surprising how much I care about micro-optimizations, when in reality they (usually) only matter in really performance-intensive code, lol.

[wynnrar (thwarted)]

@FunnyOldWorld

Creating table literals with explicit numeric indices, such as { [1] = 42 } , is now noticeably faster, although list-style construction is still recommended.

This could be massive. This syntax used to put the index in the hash portion of the table which would add overhead. From my very limited testing this seems to slap these down in the array portion. The optimization is the least important part. next, at least in vanilla Lua, prioritizes the array portion of the table before moving to the hashmap to iterate, and it does it in order. Even though this behavior isn’t defined, this change makes it so tables created with explicit numeric indices can be iterated on in order with pairs and next.

more room for me to be lazy

[zeuxcg]

@wynnrar

This syntax used put the index in the hash portion of the table which would add overhead. From my very limited testing this seems to slap these down in the array portion.

@wynnrar

Even though this behavior isn’t defined, this change makes it so tables created with explicit numeric indices can be iterated on in order with pairs and next .

Yup, you are correct on both counts.

[caviarbro]

@FunnyOldWorld

The existing ‘TableLiteral’ lint now flags cases when table literals have duplicate numeric indices, such as { [1] = 1, [1] = 2 }

Thanks a lot for adding my feature request!

[Fifkee (Noire)]

WHAT
WHAT
WHAT

y’all had me screaming in class .
WE HAVE GENERIC FUNCTIONS AGAIN WOOOOOOHOOOOOOO

THIS IS HUUUUUUGE
(p.s. thank you! <3)

[LucasMZ_RBX (LucasMZ)]

Something I want to report, Luau’s script editor at the moment thinks having (...) -> () as a function definition is valid, which it isn’t, as you need to specify the type of the arguments (...any) -> ().

It throws out an error, but the editor doesn’t seem to think it is invalid code.

[Pokemoncraft5290 (Based)]

@FunnyOldWorld

• Vector3.new constructor has been optimized and is now ~2x faster

Did this improve Vector3 math as well, since it creates new Vector3s?

[zeuxcg]

No, it was already using an optimal construction path, this only refers to explicit calls to Vector3.new

[OutlookG (Outlook)]

@FunnyOldWorld

Performance improvements

• Vector3.new constructor has been optimized and is now ~2x faster
• A previously implemented optimization for table size prediction has been enhanced to predict final table size when setmetatable is used, such as local self = setmetatable({}, Klass)
• Method calls for user-specified objects have been optimized and are now 2-4% faster
• debug.traceback is now 1.5x faster, although debug.info is likely still superior for performance-conscious code
• Creating table literals with explicit numeric indices, such as { [1] = 42 } , is now noticeably faster, although list-style construction is still recommended.

You love to see it.

Is there any updates on type-checking being taken into account by the code compiler and providing a performance boost for games?

[zeuxcg]

Not yet, sorry!

This requires analyzing our type system for what’s called soundness - specifically, augmenting the type engine with extra information about when it’s basically 100% confident in the type vs where the type may be a lie, such as due to use of ::. Right now we’re fully focused on making sure that the type checking core is robust, helpful wrt inference results, and more unified between nonstrict and strict modes, as right now the type inference engine makes very different decisions between these two modes. Only after this work is done will we be able to start looking at soundness properties of our type system.

Additionally, the exact knowledge of types in practice can help us in two ways:

• Advanced compiler optimizations, such as being able to reuse computations between different parts of the code when we know the exact types
• Just in time compilation, where the extra overhead for checking the types, which is comparatively small in the interpreter, becomes comparatively large.

We aren’t doing these yet… but we plan to! So stay tuned but give us time, nothing in this realm will ship this year.

[DataBrain (Amber)]

@zeuxcg @FunnyOldWorld

Hey, I got a sneak peak of this bidirectional type inference feature and found a major bug with it which I was unfortunately too busy to create a bug report about before this announcement. Hopefully this can be fixed easily without too much hassle? I love the bidirectional typing, and it’s easy to work around this bug by either annotating all parameters, or annotating none of them.

EDIT: See Bidirectional Typing gets borked when annotating some but not all parameters in a callback for a public bug report

[bmcqqq]

An optimization to closure allocation was released a few weeks back that affected closures without upvalues. Last week, it was further enhanced to closures with upvalues:

Is there any way we can know what the “complex microarchitectural conditions” are? This optimization, while effective, seems risky in some ways (mostly when combined with setfenv), and it would be nice to know what the conditions are to avoid running into issues.

[zeuxcg]

This optimization is currently only active in Studio and waiting for mobile updates for us to fully test on live games. In the next recap we should know if it’s good enough to stay or not, and subsequently we’ll release more information. However it’s important to know that, if that optimization stays, we won’t promise that the conditions for when it activates are set in stone (they may change in the future).

The interaction with setfenv can be very roughly summarized as “if setfenv is used with a new table before the closure is created, the closure allocation will not be elided”.

[WheretIB]

I’ve replied in the bug report topic, but for visibility here:
We’re going to disable bidirectional type inference for function arguments until the fix is released.

[LucasMZ_RBX (LucasMZ)]

@FunnyOldWorld

Creating table literals with explicit numeric indices, such as { [1] = 42 } , is now noticeably faster, although list-style construction is still recommended.

Sorry if I sound dumb here,

This is something I’ve been wondering for a while,
Apparently Lua has some issues with specifying a number index on the table constructor, on which that index will be stored in the hash part instead, even if everything inside that table constructor is in order and shaped exactly like an array.

Is this optimization about that? If not, I was wondering if this was ever changed in Luau?

[BenMactavsin]

Answer is yes, it has been answered in this very same post already:

@zeuxcg

@wynnrar

This syntax used put the index in the hash portion of the table which would add overhead. From my very limited testing this seems to slap these down in the array portion.

@wynnrar

Even though this behavior isn’t defined, this change makes it so tables created with explicit numeric indices can be iterated on in order with pairs and next .

Yup, you are correct on both counts.

[stravant]

Why doesn’t this function work?

function assertValue<T>(a: T?): T
	assert(a)
	return a
end

[WheretIB]

It should work.
Do you have Studio version 500?