How big are variables?

ID:151381
 
Apr 11 2011, 2:41 pm
Sorry, two newbish questions here:

- How "big" are the different variable types in BYOND when they are null? All the same size? (I.E. var/obj vs var/list vs var/num, etc)

- How detrimental is it to resources to have a large percentage of variables that will remain null? If I have 40,000 objects and over 100,000 empty variables, is this going to cause performance problems?

I ask both these questions in an effort to determine how necessary it is to be granular with type declaration. For example, theoretically which is better if one plans to have a lot of objects:

This:
obj
    var
        hp
        cost
        damage
        skill
        lightradius
        burntime


Or this:
obj
    var
        hp
        cost
    sword
        var
            damage
            skill
    torch
        var
            lightradius
            burntime


Cheers

-- John M.
Apr 11 2011, 3:10 pm
It depends on the type of variable and what is contained within it. Numbers seem to be the smallest while icons are probably the largest. (I would say atoms/datums but they're just references).

As to lag, I don't believe much is caused when the variables are null, though I've never had the opportunity to test it myself. Regardless, try not to make variables that can easily be handled by another plus an operation of some kind. For example, if my attack damage is my strength*2 I really don't need a variable just for my attack damage, instead I can just call the operation when necessary. Then again, there are some cases where saving the result of an operation can be beneficial, such as if the operation is taxing on the CPU (icon operations,etc.)

That's just how I see things though.
Apr 27 2011, 9:20 pm
BigJMoney wrote:
Sorry, two newbish questions here:

- How "big" are the different variable types in BYOND when they are null? All the same size? (I.E. var/obj vs var/list vs var/num, etc)

I don't know the internal workings of BYOND, but I would assume the size of each individual variable in memory is dependent on its type and value. An object reference is a pointer to another location in memory, but that location is larger or smaller, depending on how many, and what kind of variables the object being referenced has. A list is still a special kind of object, but is smaller than atomic objects. A single variable depends on it's value (I would assume). So "a" is going to use less memory than "abcdefghijklmnopqrstuvwxyz".


> - How detrimental is it to resources to have a large percentage of variables that will remain null? If I have 40,000 objects and over 100,000 empty variables, is this going to cause performance problems?

I would say this depends on what exactly you're doing. If you have this many objects sitting around doing absolutely nothing, there might be no reason for them to be there at all.

When it boils down to it, it's not the variables you need to be too too worried about, it's the functions.


> I ask both these questions in an effort to determine how necessary it is to be granular with type declaration. For example, theoretically which is better if one plans to have a lot of objects:

The second one is better, not just for the sake of having lots of objects, but for readability, cleanliness, and it's just better practice overall.
Apr 28 2011, 7:15 am
In response to F0lak
F0lak wrote:
BigJMoney wrote:
Sorry, two newbish questions here:

- How "big" are the different variable types in BYOND when they are null? All the same size? (I.E. var/obj vs var/list vs var/num, etc)

I don't know the internal workings of BYOND, but I would assume the size of each individual variable in memory is dependent on its type and value. An object reference is a pointer to another location in memory, but that location is larger or smaller, depending on how many, and what kind of variables the object being referenced has. A list is still a special kind of object, but is smaller than atomic objects. A single variable depends on it's value (I would assume). So "a" is going to use less memory than "abcdefghijklmnopqrstuvwxyz".

True, though I suspect in his case, most of those variables will be null. I'm not certain about this (since I too am uncertain about BYOND's inner workings), but I would assume that if a variable hasn't been set to any particular value that it doesn't take up any space in memory, whether or not it is defined as a variable of a given type.
Apr 28 2011, 2:05 pm
as most of the other posters have stated it doesn't make much difference.

If a variable is defined as null in the hardcode thats its default and defaults are not saved, they are only saved if it is changed. and usually gives about 0.01-0.25kb for a standard one line variable. lists depend on how many items are actually inside the list and range to greatly to give an amount.

Personally i believe variables should be defined where they are needed.
so id opt for the second option where damage and skill are defined under sword and not obj.
~midge
Apr 28 2011, 2:17 pm
In response to Midgetbuster
Interestingly compartmentalising into datums will help avoid variable redundancy, and if done well, would probably reduce overheads too.