LÖVE

Let's straight to the point with no useless chit-chat.
- What's the difference between these codes?
- Which code is more expensive in performance to run? Surely that Lua now has int subtype (as in 5.3).

That's just for integer and floating-point numbers. But what about these kinds of changing values? Are they expensive to run?

In first example, there is no difference. LÖVE uses LuaJIT which runs equivalent of Lua 5.1, so it doesn't have integers. Still, double precision floats can represent integers exactly, so it's hardly relevant.

In second example, first is assigning boolean (logical) true value to the variable, second creates a table containing boolean true as its first element and assigns that to the variable.

In third example, first creates a literal string containing text "1" and assigns it to the variable, second assigns number 1 to the variable.

Operations that work upon complex types (as opposed to primitive types such as nil, booleans and numbers) tend to create garbage, and by extension are more expensive. Tables also have the lookup operation overhead, for each level of lookup depth. Note that global variables go into global table and require a lookup from that table to reference one; local variables are allocated on stack and are accessed directly.

Ah, sorry for the less explanation about what I'm truly asking for.

raidho36, what I'm asking is that not in LuaJIT but Lua 5.3. I saw the source code of Lua, and lua_Number uses union, so both int and float require same memory space. Forget about the numbers. What about the the 3rd and 4th example? I don't know how Lua handles booleans, tables, and strings. I'm pretty sure that strings and booleans use char type, right? How fast are those examples could run? It's not like booleans and tables need the same memory space, tables are mutable so it needs more memory all the time.

Ortimh wrote:How fast are those examples could run?

O(1), which basically means they take the exact same (constant) time, as far as you should be concerned with creating one variable with them.
Changing them would be O(1) again for boolean, number, string (even if it uses a hash table, that's still a non-issue), and it'd be O(2) for tables because of one extra access... which is still constant, so O(1).

zorg, thanks! Could you give me the source of information you got from, or explain more perhaps?

Well LÖVE doesn't use Lua 5.3 so that's not quite relevant.

In 64 bit system, performance of any integer operations up to 64 bits in length is constant, since that's a size of one register and the processor would normally be optimized to handle the whole thing in one go, therefore there is no performance gain to be had from only using a fraction of it. X86 and derivatives usually have very fast floating point unit, simple float operations are usually as fast as simple integer operations. Complex operations performance may vary; it is always slower, however as far as practical evidence goes, complex floating point math is substantially faster than equivalent integer math. There is no difference between single and double precision computation performance, both are internally converted to at least 80 bits floating point numbers, possibly more depending on processor model. ARM processors is a bit different story, they suffer noticeably from using double precision numbers and their floating point unit is in general not as advanced. There is also cache hit rate to be considered, but in context of Lua that can not really be managed beyond using consecutive integer keys in the same array during data grinding.

Lua strings are byte arrays accompanied by length indicator variable. Whenever string needs to be created, pool of existing strings is checked and reference to existing string is returned if it's there, otherwise new byte string is created. String equality check is therefore O(1) and at that is extremely fast, but dynamic string management may have substantial overhead.

Lua tables are comprised of two parts: array part and hash part. All integer keyed values that the table deems worth resizing the array part for go into array part, everything else goes to hash part. Access complexity is always O(1) but keys from array part are indexed faster since there is no hash evaluation. Every time you use brackets construct a new table is created, if you let go of it e.g. by using it as a transient container, it becomes garbage and contributes to GC overhead. Same goes for temporarily existing strings.

Wow, raidho36! That really clears up my mind! Thanks. Also what I'm asking is Lua in general not Love2D's Lua. Thanks for the huge information again!

In short, all of your examples should take about the same time during execution except for: which allocates a new table and that is always slower.
If "variable" is global then you have "global assignment" which is slower compared to using locals.

Like raidho36 said, literal values are handled quite fast, as opposed to string operations (string., "..", or table.concat).