Pirate Wave Defense Core Script

[Autterfly]

I’m not sure how to address this. All of these points so far have been outlandish and/or wrong.

@4thAxis

This is the transpilation source code of Lua to C

This is the Lua source code. This is what runs on your computer when you run Lua. Lua isn’t self hosted, it’s a language made in C. Roblox’s implementation is a fork of the Lua 5.1 C implementation.

@4thAxis

Onedar was talking about the compiled stack not the Lua stack since that has no significance in his argument because the Lua stack gets transcompiled into C.

The compiled (hereafter “native”) stack is irrelevant; the native stack is constantly changing whenever Lua calls into Roblox code or Roblox code into Lua or native functions entering and exiting.

What does “the Lua stack gets transcompiled into C” mean? Lua’s stack is an array of values in on the heap. The lua_State struct in the source code has a stack field which refers to it, and 2 fields (top, base) to help identify which parts of it are active. When Lua code is compiled, it compiles to a bytecode format which runs in the Lua interpreter.

The bytecode comes with the variable offsets baked into the instructions. Instead of “access variable abc”, you see “access variable at index 4” for example.

The reason you see local variables having faster lookup times is because internally it’s an array index. It just indexes from the Lua stack, which is on the heap. Alternatively, if abc was a global, a GETGLOBAL instruction would be produced, which does a dictionary look-up over the environment table that getfenv(1) normally returns.

@4thAxis

Yes, the Lua stack and Heap are stored as a simplistic structure but for transcompilation time only

I’m not sure what this refers to. The Lua stack is stored on the heap. The heap is just available and allocated RAM pages.

@4thAxis

Check the provided sources from Onedar’s responses.

His sources are for the native stack, which like I mentioned before has nothing to do with this.

@4thAxis

Defining a local variable is 0.0014950000191759 seconds faster than a global based off of these benchmarks as shown before: Benchmark

In Lua, because, as I explained, declaring a global involves a dictionary which is orders of magnitude slower to access than an array. If you test this on any compiled language (C, C++, Rust, etc) you will find that heap allocated values in those languages are at worst ever so slightly slower than stack values.

It is a rounding error usually, and only shows itself when you are dealing with gigantic amounts of data. This is because of the CPU cache and other optimizations in the hardware. These optimizations generally don’t affect Lua, because Lua is a language hosted on top of C. It is not running directly on the CPU.

[NeoInversion (Inversion)]

@4thAxis

This is the transpilation source code of Lua to C

It’s the what now?

@4thAxis

you want to worry how C compiles and deals with the stack from Lua

You shouldn’t have to worry about the binary generated regardless of compiler, which is what I assume you’re trying to say by “how C compiles”.

@4thAxis

I’m pretty sure Onedar was talking about the compiled stack not the Lua stack since that has no significance in his argument because the Lua stack gets transcompiled into C

The Lua stack doesn’t get “transcompiled” into C. It is as @Autterfly says, the Lua stack is merely a heap-allocated array. C isn’t “transcompiled”, much less at runtime.

[angrybino]

It significantly does. Onedar ran some tests and pairs was 0.1167416118551 seconds slower than ipairs for 100 elements amortized. Benchmark: Benchmark
You say that’s negligible but what happens if you wanted to misuse pairs 6 more times? You will end up seeing much more substantial performance drops in your code. Now you might say what if I only use pairs in some places and ipairs in some places? That only just brings inconsistency and miss-context to your code.

What? The difference is negligible. When I did a bench mark with about 500 elements in a table, pairs was only slower by 0.04 seconds. You’re also wrong about the “mis-use of pairs”, you should use Ipairs when you want to loop definitely and stop at a nil value and pairs when you want to loop indefinitely and not stop at a nil value.

Not to mention the fact I’ve seen a lot of uses cases where you want to loop through an dictionary definitely.

Generally most normal people use pairs on sets containing non-numerical indices and people use ipairs on sets that do contain numeric indices.

Ipairs was never made to be used only on arrays, it was made so you can loop through tables in order and not indefinitely. Just because other people use it and you don’t doesn’t mean there will be inconsistency in code.

“Not to mention the fact I’ve seen a lot of uses cases where you want to loop through an dictionary definitely.”

The performance difference is pretty big. There is a huge performance drop when you define a global.

This is just incorrect information you’ve given here. It is necessary to backup your post with some proof. The performance difference in no way is big, it is negligible and you should use globals when they are needed, they exist for a reason. The rest is explained by Autterfly so I won’t bother anymore to explain my point here.

** [Small Edit] **

As Autterfly said, global variables are added to an dictionary which is known as the global environment (slightly slower indexing than arrays) and correct me if I’m wrong; whenever you declare a global variable, an instruction SETGLOBAL is invoked. These are what makes global variables negligibly slower than local variables.

As tested from your code, only about 0.0003 seconds of difference, I don’t know how this is a big performance cost.

[Autterfly]

@SilentsReplacement

Ipairs was never made to be used only on arrays, it was made so you can loop through tables in order and not indefinitely. Just because other people use it and you don’t doesn’t mean there will be inconsistency in code.

This better come with a really good citation. ipairs is made for arrays specifically, it’s just how it’s designed, and it can run indefinitely.

There’s really no reason to use pairs over ipairs for arrays, especially when the latter conveys much better what its parameter is.

[Autterfly]

If you want to loop through a dictionary to begin with you use pairs. If you want to loop through an array you use ipairs, because it doesn’t work on non-numeric non-ordered keys. Assuming what you meant was looping through an array in a random order, you would use neither. pairs doesn’t guarantee any kind of ordering, not even random. You’d want to use some combination of math.random and table.remove at this point.