ID:151381
 
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.
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.
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.
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.
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
In response to Midgetbuster
Interestingly compartmentalising into datums will help avoid variable redundancy, and if done well, would probably reduce overheads too.