Faster Lua VM: Studio beta

I can’t wait for this to get fully released to the public. This could mean a potential life safer!

Whenever possible, I’d appreciate it if my game could be moved over to the new Lua VM.
ID: 1080039206 (PlaceId)
I’ve tested it in studio and fixed a few issues, so it should be fully compatible.

Would there be any speed or obfuscation benefits if I merged modulescripts into one script? Right now I lazily load modules by __call-ing _G: local md=_G'md' (call not index because they can yield)

The merged script would probably be like:

local loaded={}
local modules={}

function modules.md()
local md={}

loaded.md=md
return md
end

function modules.md2()
local md=(loaded.md or modules.md())
end

Let’s say I wanted to do the following:

local _ENV do
  local environment = getfenv()
  _ENV = setmetatable(
    {},
    {
      __index = environment
    }
  )

  _ENV.string = setmetatable(
    {
      -- add modifications here
    },
    {
      __index = environment.string
    }
  )
end

However, I never actually directly modify the Environment, but refer to the _ENV variable every time. Would this still cause optimizations to be disabled? Initial testing shows it actually increases performance, but not in any real benefit.

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.

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.

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

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

3 Likes

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


I kinda relied on reading these in the old format :confused:

8 Likes

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

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

This reply might be worth reading, then.

3 Likes

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.

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.

1 Like

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.

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.

1 Like

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.

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.

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.