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.
When I do tests like these I generally get fluctuating results even without the VM, should I be aware of significant differences otherwise?
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.
1 Like
Thank you, I’ll be testing this when I get home.
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.
Thank you, makes much more sense to have a clean slate. But I don’t think instance spawning should affect the code in general? Those are separate threads am I wrong?
Separate virtual threads running on a single system thread. It basically yields one thread while executing another.
It depends. We currently don’t do any inter-module analysis so you may get some performance wins if you merge local functions and locals, but if you just put two module tables along the lines of what you’re suggesting then there’s not going to be any difference. If modules are mostly independent there’s not really any point to merging for either reason.
1 Like
Will table.insert and table.remove be more optimized? I currently use tbl[#tbl + 1] and tbl[pos] = nil to add and remove values. Sorry if I’m asking too much.
I think a ton of people (including me) use this type of removing but like it always had been, it can create empty values in a table if not used correctly.
This would make a table not only a mess but can create headaches down the line if your storing a bunch of values at once.
You should always substitute each removed value with another one so that one, it never goes unused, and two, it’ll save space.
The VM should help with this, but realistically the difference shouldn’t Ben noticeable unless your adding and removing from a table like 500 times per minute.
Is it possible for us to manually enable the VM via studio and apply to the game itself?
I have a number of games that could use the extra speed but I have no idea if they’re eligible for it.
Would be nice, thanks!
You can test the vm in studio by being in the beta program and enabling it under the beta features.
Currently you cannot apply it to your game. The staff has to do it manually by changing the fflag.
2 Likes