I’ve worked on something similar in the past. The drastic difference is performance is due to the constant render updates (I’m assuming you’re using 1 frame per pixel), not Lua performance. I’d suggest you focus on reducing and reusing “pixels”.
Performance updates are always welcome. Love this!
I am not using any GUI objects such as frames and instead I am using one sided planes. I will also note that I still get a solid 60 FPS rendering all 320x180 of these planes if I don’t change their color while still storing the output pixels to a table instead of the grid of planes.
Any changes to any object queues a render update, whether it be 2D or 3D. Constantly updating properties (position, size, color, etc) will lead to constant render updates. This is expensive and the primary cause of your low performance. Again, it has nothing to do with the new Lua VM.
You are rendering 320x180 planes, or 57600 meshes. I really don’t see what’s confusing about the issue.
A single mesh with 10000 triangles is more efficient than 5000 independent planes.
Every class in Lua is either a userdata or a table and creating a new object will always involve some overhead. In your case, saving positions involves just bringing a few bytes into memory, thus the 60FPS. Taking those positions, rasterizing them, and applying the result color is already slow on the Lua’s side, but then that data has to be updated and imagine having to process thousands of meshes just because you moved by an angle.
1 Like
i can’t wait until this feature is officially released, soooo many games are gonna benefit from this
I suppose you are right about the bottleneck being Roblox’s rendering stuff. Here’s what the microprofiler and task manager reports while I am rendering a more complex mesh on a 360x360 grid.
It looks like the performance bottleneck on my machine is CPU bound in the microprofiler, but only a fraction of my machine’s compute resources are being used. Could you be more specific as to what software and hardware components are limiting my rendering engine’s performance?
1 Like
I went on my zombie test place and compared the game’s performance with the old Lua VM and the new Lua VM.
Old Lua VM = 25 FPS Average
New Lua VM = 52 FPS Average
Pretty impressive, I did not make any changes to the scripts when comparing.
I hope you guys are not done with optimizations and optimize it to the max :3
3 Likes
Faster Lua VM Is Best, this probably will reduce the lag, or get best possible scripts.
And this is awesome to run faster, this can make game a lot better!
1 Like
So meaning we won’t have to make any changes to our games and scripts within, they should run the same?
It was previously pointed out that most scripts will run correctly, but some features like environment manipulation will disable the optimizations.
Also, stuff like :
will no longer work.
Would game:GetService() still work?
1 Like
Yes, the proper way to retrieve a service is through the GetService function.
2 Likes
I ran some tests on my vehicles and how long it takes to run the calculations between the old VM and the new one. Discounting a wait() call (I ran the tick calculation before the wait), I averaged about a 50% improvement across the board. That said, there were outliers from the new VM that were a bit concerning compared to the old one. Some times (roughly 10%) were substantially higher on the new VM and less consistent compared to the old VM. There were a few instances where the time was 200% or even 300% of the average that were not the case with the old VM. The old VM was extremely consistent in its time, only deviating about 30% at the most. Overall the new VM is still faster, but the inconsistency in the new VM is a bit of a concern. Both tests were run in identical circumstances save for the beta VM being enabled/disabled.
3 Likes
If you send us a repro we can take a look.
4 Likes
Back with another observation about the new Lua VM that blew my socks off while looking into an issue I was having with Blox (details about that above!).
This time, I was measuring the time taken to generate a bog standard, 128x128, 64 block high world:
I ran 10 tests on the new VM and then 10 tests on the old VM.
For the old VM, I got an average time of 8.7047 seconds to generate a world. Sounds pretty reasonable, right?
For the new VM, I got an average time of 1.2293 seconds. That is over 7x faster 
What’s more, the new VM appears to be more consistent from this (admittedly kinda small) data set.
Here’s some numbers and two pretty squiggles:
That’s a profoundly big gap. Imagine all the extra fancy stuff I’ll be able to pack in there!
So yea, thanks zeux and co for this little surprise tidbit I found while measuring up Blox! 
22 Likes
So get me if I’m wrong, this update is to just allow our scripts to run even faster while getting rid of support for really unconventional programming that nobody teaches or taught in the way that is no longer supported?
local part, position = workspace:FindPartOnRay(ray, Player.Character, false, true)
Would that still work?
1 Like
The only thing that is being removed is ability to call methods without using the actual method call syntax. The syntax game("GetService", "RunService") - note that here the object game is being called as if it were a function! - was never officially supported, and didn’t even exist up until 2 years ago or so. Everything else should work as usual, including all examples you list.
5 Likes
Oh, okay so all current and supported code should be supported in the new VM
1 Like