I’m almost certain it’s the debugger having to interpret newlines, which is why it doesn’t do it in the command line
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)
1 Like
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.
1 Like
Aaaaaand got it
I just disabled the Lua debugger (option in studio settings > Studio > Lua), restarted studio and ran my code again:
0.024985313415527
0.025152444839478
0.02470850944519
0.024580717086792
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.
8 Likes
Stop trying to micro optimize your code by trying to make it easier for the parser. Whitespace has literally no bearing on speed.
3 Likes
While this is a bit of a tangent, yes, you shouldn’t optimize code to the point of unreadablility.
Roblox doesn’t compile code. That would take way to long and use more resources on roblox’s end.
Roblox more than certainly compiles code, otherwise string.dump wouldn’t be outputting Lua chunks.
1 Like
I don’t know how to respond to that except: yes, they definitely do compile code.
1 Like
No? If they used a compiler you wouldn’t be able to get live errors, which is something unique to an interpreter and not a compiler.
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.
Read up here
That is entirely not what string.dump does.
Odd, because if it is a compiler the error tracebacks wouldn’t be possible as compilers just run the code errors or not, where as interpreters stop once there is an error found but runs all of the code above the error.
You could swap the two blocks around and then ask why adding whitespace speeds up your code.
The better question to ask is why subsequent iterations of the same code are faster. You can probably blame the CPU cache.
2 Likes
If there’s a parsing error, no single line of code will be executed. If there’s a running error, e.g. an error that happens during runtime, the thread will stop at that point, which might mean some code has already run.
The bytecode contains “debug data” which says e.g. “this instruction here was defined on this line” or “this local here is called this”, which can be used to create proper stacktrace things.
With the exact same (byte)code (apart lineinfo), the CPU shouldn’t handle it differently. Would be a bit too low-level for Lua anyway, as the cache would most likely affect the VM.
We kind of solved it, and it’s basically roblox doing a roblox thing again