Faster Lua VM: Studio beta

[Amiaa16 (Amia)]

@Reinitialized

I never actually directly modify the Environment, but refer to the _ENV variable every time

I believe it doesn’t matter. What matters is that you called getfenv(), so your function/script has been “marked” as using it, therefor disabling the optimizations.
But I guess let’s hear it officially.

[zeuxcg]

We’ve enabled the new VM for places listed in the previous message for all platforms including mobile and console, as well as for a couple of extra places for people who asked.

Reminder - if you own a popular game and would like the new VM to be activated for your game on your timeline please let us know.

We plan to run a full-scale production test of new VM with it being active on all platforms/places online (with the exception of Studio) next week.

[Reinitialized]

I’d also like to have the VM activated here so I can further test it within a proper online environment: 3489740016

[Arch_Mage]

Hi, could the new Lua VM be enabled in Rogue Lineage? (ID: 3016661674)

We think it would help with client security.

https://www.roblox.com/games/3016661674/Rogue-Lineage#!/store

[BuildIntoGames (Preston)]

Minor inconvenience but I noticed the stack trace changed in the new VM:

I kinda relied on reading these in the old format

[XAXA]

PSA: Please don't rely on the format of `debug.traceback` results

During testing of the early version of our new Lua VM, we found a few games that relied on the precise format returned by debug.traceback function. This is a PSA asking to change code that relies on that - be aware that we reserve the right to change the format without notice. The changes have to do in part with the cleanup of the resulting format that make it match stock Lua better, and in part due to fundamental differences in how new VM works and what it can support. Here’s an example of de…

[BuildIntoGames (Preston)]

Thanks, didn’t see this mentioned or linked to the thread.

[SmartNode]

I have mixed thoughts about this new upcoming update mainly everyone is hyped about.
I’m a developer that codes with optimization techniques naturally (memorization, using locals and global when necessary, avoid inefficient rendered code) and I was wondering since I progressively get better in this area, this VM should render my techniques useless?
If not then would it become worse? I’d hate to undo the little tricks that the new VM implements because if I already make the script faster, I’d like this VM to help me, not neutralize it. Thanks

[XAXA]

This reply might be worth reading, then.

Faster Lua VM: Studio beta

This has been stated many times already, but ok, here were go again. You don’t need to rewrite code. If you have code that runs slower than it does in old VM, you can report this as a bug. If you have code that doesn’t run as fast as you’d like, we can look at what the performance problems are. If your code has a performance problem with for loops due to use of next or localized pairs, we can implement an optimization for this. As stated before, all code we’ve looked at so far doesn’t do either…

[nooneisback]

You can point that out as much as you want, but that doesn’t change the fact that the old VM will no longer be the standard of comparison. If your old code that you carefully optimized runs slower, then you will obviously have to rewrite it instead of blaming the old VM and leaving it be.

[Amiaa16 (Amia)]

Your code shouldn’t run slower in the new VM. If it does, you can post a repro here and roblox staff might take a look at it.

[nooneisback]

Did you even read my post? The old VM should not be brought up as a standard for saying that “it will run just as fast as it used to”. Lua programs from external sources that have to be run as fast as possible will have to be rewritten to achieve the higher potential performance and new coding habits have to be learned.

[zeuxcg]

@SmartNode

If not then would it become worse? I’d hate to undo the little tricks that the new VM implements because if I already make the script faster, I’d like this VM to help me, not neutralize it. Thanks

Right now there is one instance where “localizing” makes scripts slower than not localizing, which is iteration through pairs. As noted before we haven’t seen code that does this before, but this will be fixed.

Future optimizations will also take localization into account.

In general, it’s to be expected that some optimizations that helped before aren’t as impactful. For example, several years ago it used to be valuable to cache something like workspace.IsA so that you can then call it on a bunch of different objects, but now you can just call object:IsA and it’s going to work fine.

[zeuxcg]

@nooneisback

Lua programs from external sources that have to be run as fast as possible will have to be rewritten to achieve the higher potential performance and new coding habits have to be learned.

This is not constructive.

If you have examples of code that you previously hand-tuned for the old VM and you had to adjust within the new VM so that they run faster, feel free to share it here and we can take a look at making it run faster.

[SmartNode]

How are you able to test how fast between two scripts? If I tried this even with the same script running I’d get fluctuating results.

[Automationeer (Eleanor)]

Monitor when the script starts, and see how much time had passed when the script ends.

Here’s a poorly-written-just-so-you-get-the-idea script:

local start = os.time()

local list = {‘a’, ‘b’, ‘c’, ‘d’, ‘e’}

for i,v in next, list do
   if v == “a” or v == “d” then
      wait(.2)
   end
end

print(os.time() - start) --// Returns how long the script has been running for, in seconds.

[SmartNode]

When I do tests like these I generally get fluctuating results even without the VM, should I be aware of significant differences otherwise?

[Automationeer (Eleanor)]

There can be a variety of reasons that impact how fast code runs, unless your code is obviously slower in the New VM; there is nothing to worry about.

[SmartNode]

Thank you, I’ll be testing this when I get home.

[nooneisback]

Run the program multiple times so that it runs for at least 2 seconds. Many things outside of the code in question can cause slowdowns such as physics, instance loading and property changes, also add a 5 second wait before each benchmark.