For a case like yours: why not store the local variables in a table that works similarly to _G, but specifically for each script?
I also am running into problems with the new vm taking a long time to process huge static tables
I have an 100k array of devproduct ids for prices from 1 to 100k r$, when the module returning this table (which does no work) is require-d, studio and servers freeze up for like 10 seconds
1 Like
Just curious-you have 100,000 dev products in your game??
2 Likes
yes, so players can choose how much they want to spend
1 Like
I’m not encountering that issue when making a table of that size from the command bar (filling an array with 100,000 numbers took 3ms). Are you storing these IDs in a table constructor? If so, it might be an issue with how many fields you have.
idk its a module, make sure you are in the new lua vm and require it from a server script
btw i was just kidding its not 100k yet, its like 70k, the bot hasnt made the rest yet
1 Like
Hmm. That took 28.5 seconds to load. I’m not sure why, especially considering an identical length table but with all the numbers the same loaded in almost no time at all (49ms).
1 Like
You also got to consider this framework has been around since 2015 and rewriting the whole first book of harry potter in scripting isn’t currently in mind for our team.
But regarding your comment we store them somewhat already in a self table and we feel if we make a _G like table it would just make the internal functions even more accessible to exploiters.
1 Like
I may be missing something, but I believe they’re using a program to manually create a dev product for purchases valued between 1 and 100 000 R$, with every increment in between.
The VM executes Lua bytecode and handles hooks; none of what you mentioned (save for the debugger) depends on the VM as far as I know.
1 Like
The problem is your script has tens of thousands of constants which will slow down loading. The reason Dekkonot’s was faster was because all of his numbers were the same (Only 1 constant) while all of yours are different.
1 Like
Will this break VR support ? Last time I checked Roblox studio 64 bit did not work with SteamVR
1 Like
This is really amazing! I tested the new VM on my work-in-progress RTS (test place can be found here) and saw 1.5-3X performance improvements across the board. Here’s the results from the sections of code I tested (format: old time → new time):
Client sided stuff:
Rendering units while they are standing still every heartbeat cycle: 0.001 → ~0.0005-0.0006
Rendering units while they are moving/bumping into each other every heartbeat cycle: 0.005-0.008 → 0.002-0.003
Camera and minimap updating every heartbeat cycle: 0.00015-0.00030 → 0.0001-0.00025
Selecting all units in current camera view: 0.005-0.009 → 0.002-0.003
Server sided stuff:
One run of the main logic loop while all units are standing still: 0.0007 → 0.0001-0.0002
One run of the main logic loop (all units moving around and bumping into eachother, etc.): 0.001 → 0.0005-0.0006
As you can see, most of the stuff runs significantly faster.
1 Like
I tried working on a gun framework and I agree it’s a headache. Even starting from scratch is a pain…
So, looping takes CPU time. The more square root operations you “unroll”, the less time you have to spend adding 1 to your iterator, i.
And it took like 0 effort to add the extra lines of code in, and it’s not production code, so it doesn’t have to be pretty, just fast.
1 Like
Thanks for the clarification though. I apologise for not having got back tom you sooner.
Thank you, definitely going to use this in my game when it comes out!
Can you PM me the example script?
edit: nvm, I missed the message with the model link. Will take a look!
2 Likes
Thanks for the simple repro! This was a performance bug in the compiler that only manifested on 64-bit builds, we’ve fixed this internally - the fix should ship next week.
7 Likes
