1 Like
I would say the second is the better option.
I like the first one more, not because I think it will be more performant (it could be), but because is it more readable
I’d assume the performance of both would be practically the same
If you want to reliably test performance of code, give this a watch. I can tell you that the source of lag in games is probably not what you think
These would be pretty similar except that the first one is a little smaller in final bytecode size. The second one could maybe allow the Luau compiler to perform deeper optimizations if xArea, position, and xOffset are known at compile-time (which I assume they aren’t so this probably doesn’t matter).
Why is round a local variable? I hope you aren’t writing your own rounding function, that’ll probably cause the biggest performance impact because you’d be disabling the fastcall optimization for rounding that comes with math.round (although it is pretty minor for most cases). Also, where is xHalf defined?
Overall very little would be different in terms of performance, but you can always benchmark with the Microprofiler or a benchmarking plugin to be sure.
1 Like
You should pre-size locations. That’s the biggest optimization I see here.
The second function may save you from executing one or two extra IL instructions in the best case. Not really a great difference.
Another micro-optimization, although I can’t say for certain if it would be better here and would need profiling, is to recognize that you should try using a variable i to increment instead of #locations+1. I’m not certain if Luau is smart enough to optimize that entire idiom out or not, though.