Does making variables like this decrease lag?

I while ago i read a post asking how to get rid of lag and somebody replied that scripts should only make variables once because duplicate variables cause lag, so what i thought was make a script like this

local variable = nil

while true do
variable = math.random(1, 4)
wait(1)
end

instead of

while true do
local variable = math.random(1, 4)
wait(1)
end

does this prevent lag or not?

It more or less depends on the scoping, you might wanna look at this article to see how they really work

I do not believe this to be the case, but I don’t know Roblox’s internal engine that well. However, from what I do know, creating a variable basically creating a reference to the actual object. The engine automatically allocates memory to that variable depending on how much it needs and thus would not cause lag.

but dont usually use global variables, im just wondering that since im putting local variable in the loop, it just keeps creating itself thus causing lag, or am i wrong?

Once it exits the loop it will be garbage collected. In other words, no lag.

so if i make the variable before the loop, it will stay? if so does that cause lag?

It doesn’t really cause lag, but it isn’t really “better” in this case either way. Forward-declaration is only useful if you are exiting the scope where the variable is created, and because this loop doesn’t there’s no point.

Also, if you really want to know, I would recommend asking @Hexcede. He knows a lot about the internal engine and for all I know, I could be flat-out wrong. I don’t believe I am, but there’s always room for doubt.

However, if you take a look at the Task Scheduler | Roblox Creator Documentation, garbage collection happens after waits in the script resume. I don’t really think it’d be causing lag since it’s freeing-up memory.

I am not sure how this ends up working out, but, for a lot of questions you can check out the luau source code now. In this case I’m not sure where the code related to local allocation is.

One thing I would like to mention since your example code follows this pattern, waiting in a while loop is not ideal. You’re really just spreading out lag, and slowing your code down, and if all of your code is slowed down, you might as well just be creating artificial lag.

From my understanding, the way that local allocation works is fairly smart, I would not expect the bottom case to be any faster than the top case except with millions of iterations.

Here’s a benchmark using @boatbomber’s benchmarking tool:

This is showing the time it takes for 100 reads/writes with the local defined inside and outside of the loop.

local iterations = 100
local something = 123

return {
	ParameterGenerator = function()
		return
	end;
	Functions = {
		["Read locals outside"] = function(Profiler)
			for i=1, iterations do
				i = something
			end
		end;

		["Read locals inside"] = function(Profiler)
			for i=1, iterations do
				local something = 123
				i = something
			end
		end;
		
		["Write locals outside"] = function(Profiler)
			for i=1, iterations do
				something = i
				i = something
			end
		end;

		["Write locals inside"] = function(Profiler)
			for i=1, iterations do
				local something = 123
				something = i
				i = something
			end
		end;
	};
}

As you can see, the difference is within 0.1 microseconds for both. So, while putting the variables outside the loop is technically faster, in your example the cost is only 0.1 microseconds every single second, which, is practically nothing.

You would need to be running a loop roughly more than a million times before the savings could start to have any noticeable effect on the framerate (>1+ms) at which point the cost of the read/write itself is significantly more expensive.

Plus, this is bound to change plenty, so, really you should just follow whatever makes the most sense from a programming point of view, and if you need to change it for a large loop, you can.

3 Likes