Forum

> > Off Topic > Changing Values in Lua
Forums overviewOff Topic overviewLog in to reply

English Changing Values in Lua

7 replies
To the start Previous 1 Next To the start

old Changing Values in Lua

Dousea
User Off Offline

Quote
Let's straight to the point with no useless chit-chat.
• Is there any difference between these codes?
• Which code is more expensive in performance to run?
Code 1
1
2
number = 1.5
number = 3
Code 2
1
2
number = 1.5
number = 3.0
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?
Boolean to table
1
2
variable = true
variable = {true}
String to number
1
2
variable = "1"
variable = 1
Are they expensive to run?
edited 1×, last 10.12.16 12:35:35 pm

old Re: Changing Values in Lua

Baloon
GAME BANNED Off Offline

Quote
user Dousea has written
1
2
variable = true
variable = {true}

As I know, the better way to use booleans is on line 1 which is not in a table.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
var= true
if var then print("abc") end
>> abc


var= false
if var then print("abc") end
>>


var= {true}
if var then print("abc") end
>> abc


var= {false}
if var then print("abc") end
>> abc


var={false}
if var[1] then print("abc") end
>>

old Re: Changing Values in Lua

Dousea
User Off Offline

Quote
Ah, sorry for the less explanation about what I'm truly asking for. 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 same memory space, tables are mutable so they need more memory all the time.

old Re: Changing Values in Lua

EngiN33R
Moderator Off Offline

Quote
In the C API, booleans are represented internally with the
int
type.

Since Lua 5.0, tables have a somewhat more sophisticated implementation. Each table has an array part and a hash part. In short, the array part stores "array values", so dense numeric indices, and the hash part stores associative values. More info is available in section 4 here and, of course, in the source code.

old Re: Changing Values in Lua

DC
Admin Off Offline

Quote
1 and 2: should be quite equal. Lua only has one number data type which is a double. It's possible though that 3.0 is slightly slower because you simple have more digits to parse. I'm not sure about this though.

boolean to table: of course creating a table (2) is more expensive than simply assigning a bool (1).

string to number: strings are always, in any programming language I know, more expensive than plain values. So 2 should be faster than 1.

At least this is how it should be. I didn't profile it. To see the actual difference in performance you should run the operations a lot of times and see how long it takes.

old Re: Changing Values in Lua

Dousea
User Off Offline

Quote
Okay, thanks everyone. I think I got all of your points and went straight to my brain. I asked the same question in Love2D forums and these are the answers that I got.
zorg has written
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).

raidho36 has written
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.

ivan has written
In short, all of your examples should take about the same time during execution except for:
1
variable = {true}
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).
To the start Previous 1 Next To the start
Log in to replyOff Topic overviewForums overview