We kind of solved it, and it’s basically roblox doing a roblox thing again
I mentioned it because I got a same or similar behavior in standalone Lua.
We kind of solved it, and it’s basically roblox doing a roblox thing again
I mentioned it because I got a same or similar behavior in standalone Lua.
Aren’t those time differences insignificant? I just blamed it on CPU scheduling combined with the unpredictable CPU time requirements of other processes and such.
one can only over-optimize so much
Perhaps that’s the case. I tried running the loop several times in succession, and the difference becomes less noticeable as count
is increased. I think only the very first iteration in the first set is taking slightly more time.
-- First set apparently takes more time on average
local tick = os.clock
local count = 10000000
for i = 1,10 do
local start = tick()
for i = 1,count do
local a = i
end
print(tick() - start)
end
-- Extra time diminishes to nothing
local tick = os.clock
local count = 1000000000
for i = 1,10 do
local start = tick()
for i = 1,count do
local a = i
end
print(tick() - start)
end
The cache definitely matters, even for interpreted code. Lua’s bytecode based execution is tight enough that speed differences due to caching will absolutely be detectable.
Yes, but since it’s the same bytecode (and lineinfo doesn’t get used until a traceback has to be generated), so I’d assume the cache would be (in theory) the same for code blocks.
Note: Roblox never downloads source code while not in studio. Instead Roblox sends bytecode to the client.
Roblox’s client doesn’t even have a Lua compiler anymore to make it harder for exploiters.
Minifying code may still technically have performance benefits as shorter strings are used, but it’s trivial, so do not change your programming style for “performance gains.” Instead, write readable code you can analyze and optimize.