ID:265894
 
I would like to know which of these methods are the less efficient.

First(an associative list, which makes much more sense in my opinion, even if it's with only one element) :

mob/var/list/Age = list( AGE = AGE_TIMER )

// AGE would be a number and AGE_TIMER would be the value\
of time for the next incremention on AGE


Secondly, two vars..

mob/var
Age
Age_timer


I would use the first one, but I'm not sure how much of a disadvantage it's in (if it's actually in one) compared to the two vars.

I actually have some other stuff I want to implement which go with the same basis as this, so I'd really like to hear an answer on this.

Thanks :)
My guess would be that the list is the least efficient but maybe you are going to use it in a whole differend way than I'm having in mind.

I think instead you might want to start wondering which would fit best for it's purpouse and would be easiest to handle/manipulate in the future.
It doesn't really matter with BYOND's new object limit :P. An age list is still rather wasteful, though, if you're only placing one thing into it. It also won't work if AGE is a number.
In response to Jeff8500
The limits aren't the only thing you have to look at when you're comparing their efficiency.

The two points that stand out most for me are speed and extensibility.

Lists are modular. You can add features to list-based calculations much faster and easier than having to add individual variables.
Lists are also slower. They are slower to initiate, and slower to access. If you are doing anything short of 1000's of calculations per second then it really wont make much of a difference process wise as long as you write your code efficiently.

So in my opinion extensibility is the more important factor because you really have to be doing some heavy duty processing for speed to become an issue.
In response to AJX
I'm inclined to suggest that a list doesn't make sense in this context. While an age and it's incremental timer are related concepts, I can't see any particular case where this kind of mapping between the two would prove useful. If extensibility is really your aim, then an age datum would be altogether more fitting:

age
var
mob/subject
value = 0

proc
age()
src.subject.die()

getAge()
return src.value

increaseAge()
src.value++

New(var/mob/subject, var/value = 0)
src.subject = subject
src.value = value
spawn() src.age()

human
var
maxage

New(var/mob/subject, var/value = 0)
src.maxage = rand(20,120) // It would be sucky for our humans to be still-born.
..(subject, value)

age()
while(src.value < src.maxage)
sleep(6000)
src.increaseAge()
..()

increaseAge()
..()
// Some stat changes here, maybe?

vampire
age()
while((src.subject.kills / src.value) > 10)
sleep(6000)
src.increaseAge()
..()

mob
var
age/age
kills = 0

proc
die()

New()
src.age = new/age/human(src)


The benefit here comes in the fact you can swap in/out the mechanism by which a person ages. Naturally some forms of aging are only suited to some sub-types of mob (in my example, you'd probably have /age/vampire only allow itself to be tied to /mob/vampire). You can over-ride how a player ages, the consequences of aging and in fact even what their age is reported to be (via over-riding age()). There is a bit of a catch with this symbiotic datum relationship though, you create a circular reference in this instance. As such you'd have to forcibly delete the mob to actually get it to go away. I suspect you could easily re-work the mechanism to remove the circular reference though.
In response to AJX
AJX wrote:
Lists are also slower. They are slower to initiate, and slower to access. If you are doing anything short of 1000's of calculations per second then it really wont make much of a difference process wise as long as you write your code efficiently.

Note that if you try to access a variable, it may very well be accessing a list instead; the "vars" list contains every variable in the game, and your call to mob.key may very well translate to mob.vars["key"] internally.
In response to Android Data
The only reason I say lists are slower is because I've ran a few stress tests on an air system that ran a few thousand calculations per second. With vars it was far faster than with lists, but lists were obviously easier to add new gases to.