Are there any quick tips on script layout to make things run more efficiently? I know the live compiler scans line by line, so is it more efficient to put things like short for loops/ while true do loops all on one line for instance?
1 Like
Lowering the number of lines is pretty pointless (in my opinion), it’s micro-optimisation and has almost no noticeable effect.
However, a more noticeable way would be to save things you index often (Instance.new for example) to a variable:
local New = Index.New
for i = 1,500 do
New("Part")
end
Your scripts will run slightly faster, especially when the thing you are indexing is being indexed a lot (like in the example code)
6 Likes
This is a misconception. The interpreter interprets bytecode, not raw text.
You’d need several hundred megabytes of whitespace before anything becomes noticable, and even then it would only affect the server, and only on startup.
There’s basically no situation where you’d want to golf your code.
10 Likes
Unless said code was messy, uncommented and overall unreadable. Making clean, neatly organized code would be one such reason. 
1 Like
Wasn’t this optimization implemented in Lua a year ago? At the end of this blog post, the tests ran showed that indexing a function to a variable was just as fast as not indexing it.
Huh, just ran a test myself and there doesn’t seem to be any difference.
I guess you’re right
Finna do some shameless self advertisement but…
https://devforum.roblox.com/t/why-i-dont-sleep-micro-macro-optimizing-mega-guide/71543
1 Like
Golfing messy code still results in messy code - just shorter.
4 Likes
You’re gonna make your life better if you just stick to major coding practices designed to make your code organized and readable. Only deal with performance issues if they come up.
2 Likes
I looked up “code golfing”, now I know what it means. Yes, that is a valid point. I was not fully aware of what “golfing” meant lol.
1 Like
I just read that article and can’t help but notice a big flaw with their Lua code. The performance test they were doing used isa(part, “Basepart”) in one of the tests, instead of isa(part, “BasePart”). “Basepart” doesn’t exist so the results on __call vs __namecall were wrong.
@mrdooz @zeuxcg
local part = workspace.Baseplate
local count = 1000000
local start0 = tick()
for i=1,count do
part:IsA("BasePart")
end
local end0 = tick()
local start1 = tick()
for i=1,count do
local isa = part.IsA
isa(part, "BasePart")
end
local end1 = tick()
local start2 = tick()
local isa = part.IsA
for i=1,count do
isa(part, "Basepart") -- This should be "BasePart"!!!
end
local end2 = tick()
print("namecall", end0 - start0)
print("index+call", end1 - start1)
print("call", end2 - start2)The results on the wiki:
> namecall 0.49229717254639
> index+call 0.78510332107544
> call 0.49960780143738My results after fixing the “Basepart” typo (running on a roblox server):
> namecall 0.22167825698853
> index+call 0.34116268157859
> call 0.20122885704041Some results after running my profiler for 15 minutes:
Edit: I need to sleep but part.IsA(part, “BasePart”) would be more appropriate than the second test that localizes it. I might update the results if I remember.
As for the OP, writing clean, easy-to-manage code is one of the most important things you can do. Only do ugly optimizations if they can prove themselves to be worth it through testing. I created a script simplifier for my game that I run before publishing, so I can stop worrying about doing tedious/ugly optimizations like hard-coding constants, and instead focus on writing manageable, easy-to-configure code.
Writing a Lua simplifier was slightly ridiculous, but it simplifies my game’s 100,000 lines of code in less than 20 seconds. It can do extremely complex optimizations that the Lua compiler can’t.
Before:
After:
This has changed how I write code. I can have debug-only code that simplifies away before I publish, define how non-native-Lua operations can be simplified, and finally write “math.pi” without cringing at how many operations Lua is doing just to get a constant.
3 Likes