In regular Lua it’s exactly the same bytecode, as it’s supposed to be.
@Crazyman32 since Lua gets parsed before being executed, it shouldn’t matter for that loop.
If you’re measuring time from inside the code, the code is already executing, so you can’t measure parsing difference.
Oh, maybe I’m getting confused with the LuaJIT compiler. Or I’m just wrong both ways. Anyway, that makes this much more interesting. I would be interested to see the dumped bytecode.
I think that while in studio, code is compiled into bytecode as it runs which is why the condensed version is faster, but I just tested in a live game on both server and client, and both versions ran at about the same speed on both client and server, so maybe Roblox precompiles like the other option Wikipedia says (same source) (which would also be more secure so exploiters can’t steal the lua text code directly):
Or that might be completely wrong because the running might be slightly delayed by other scripts while in the mean time the code is still compiled in parallel?
local tick = tick
local count = 1000000
do
local start=tick()
for i=1,count do local a=i end
print(tick()-start)
end
do
local start = tick()
for i = 1,count do
local a = i
end
print(tick() - start)
end
Seems the same, although I just used string.dump in studio which might output something different than what’s actually used, or what happens isn’t visible in the bytecode.
I doubt it’s the bytecode that’s doing something, seems more like it’s another VM thing. It seems like roblox is internally doing something at the end of every line (not instruction/statement), unless the newline is in the middle of a statement or so:
do
local start=tick()
for i=1,1000000 do local a = i local b = i end
print(tick()-start)
end
do
local start = tick()
for i = 1,1000000 do
local a = i local b = i
end
print(tick() - start)
end
do
local start = tick()
for i = 1,1000000 do
local a = i
local b = i
end
print(tick() - start)
end
do
local start = tick()
for i = 1,1000000 do
local a = i
local b
=
i
end
print(tick() - start)
end
Er, this seems completely random. But like @einsteinK did mention, Lua is compiled.
However, to clear some things up:
Lua is not “compiled on the go”, it’s made into a proto, and that’s what’s executed. Or in the case of server->client, proto to bytecode back to proto. There is no difference in the bytecode of each besides the lineinfo debug data, which could very well be the issue when being checked, but I doubt it.
Anyhow, here are my theories as to why this happens;
An inconsistency in the Roblox VM
Different usage of registers
lineinfo acting weird
I doubt Studio does this, but I know they also encrypt their instructions to an extent, which may slow things down.
TL;DR whitespace does not speed up code, and you shouldn’t abuse the lack of it
Actually this thing and the “script __index” Code speed inconsistency are most likely one and the same. We assumed the latter happens every instruction, but it might be every line (that isn’t in the middle of a statement), which is quite easy to do with debug.sethook, but the internal C-sided version:
You can (although in a limited way) jump between levels/identities, aka let your function run indirectly at another identity. Not really the point here.
Like @zeuxcg once mentioned in the linked thread, “it might be the debugger getting the script variable”, along with the line number (an argument passed by sethook when using 'l') for e.g. line breakpoints.
EDIT: A bit like @Dekkonot mentioned (ninja’d), except it isn’t because it interprets newlines (after compiling at least)
I’m not in a position to test it, mind you, but I’m willing to bet that if you turn off the debugger in studio or test it in an active game environment it will probably be a much smaller difference.
Still don’t know 100% of the details, but it seems to be the debugger doing something with the line sethook, most likely also requesting the script variable.
That’s… not how any of this works, at all. Unless you mean actual asm compiling vs parse compiling. But no, Roblox compiles. I suggest you take a look at the Lua compiler, which is a thing.
And as for string.dump that just returns a memory location which can be done in both execution methods. Once a function has been defined it is loaded into a ram location which can get called from at any point.