ID:1772929
 
I was browsing through the internet on my phone when I randomly thought of an interesting way to clear variables. Typically there are maximums and minimums for stat values. These variables could apply to how much wood a tree has or how much health a player has left.

What I briefly thought of was, why not clear up the variables we aren't using? It wouldn't hurt, would it? Even though we may use it a bit later. Well, the method I composed a few minutes ago in my head and wanted to briefly share it with others to get an opinion goes like so:

mob/verb
Heal()
while(hp != null)
hp++
if(hp >= mhp)
hp = null

Hurt()
if(hp == null)
hp = mhp
hp--


Now, I'm not sure how beneficial this would be. But, it was a quick thought that I felt I should get out there. I'm not sure if constantly resetting a variable would be bad in terms of CPU or if the garbage collector will do it's job on these nullified variables in time. Any thoughts?
Shouldn't hp-- be before the if statement? And I don't believe 0 = null o:
Wouldn't this go into the negative values?

[Edit]

It also sets the players hp to null since it's >= mhp

Here's how I'd go about it
mob/var
hp = 5
mhp = 100

mob/verb
Heal()
heal(10)
world << hp
Hurt()
hurt(10)
world << hp

mob/proc
heal(int)
hp = hp+int > mhp ? mhp : hp+int
hurt(int)
hp = hp-int > 0 ? hp-int : dead()
dead()
src << "yur ded m8"
hp = mhp
In response to Kozuma3
In the hurt procedure it checks if the player HP is null. If it is, this means it is the same as Max HP. If it's not, do nothing and continue. After the if check it will decrement. This is mainly for theory. Since I am writing this on mobilw, forgive me for not being thorough. I didn't even declare the variables or initialize them.

The heal function loops constantly until their HP is maximum again. Even if they are hurt. Once again, just to show my idea. What do you think about it in terms of saving some RAM from variables since this effects objects and npcs too.
In response to Xirre
Xirre wrote:
In the hurt procedure it checks if the player HP is null. If it is, this means it is the same as Max HP. If it's not, do nothing and continue. After the if check it will decrement. This is mainly for theory. Since I am writing this on mobilw, forgive me for not being thorough. I didn't even declare the variables or initialize them.

Ah I see what you mean, I think it would be pointless tho since you can only really do this for numbers.
Not worth the extra instructions you use processing.

You might want to get Lummox to answer this one, but I'm pretty sure that whether or not a variable is null, it's still going to take up the same amount of space.

I think that all variables in BYOND are 5 bytes in length. 1 Byte for the type index, and 4 bytes for the memory pointer where it's stored.

I think BYOND simply allocates blocks of raw memory at need.

Types more than likely are structured in such a way that the type class stores their variables numerically. That way, to look up an instance's variable, it just has to do this:

unsigned int *memloc = &instance_ref + variable_number*5;
unsigned char vartype = *memloc


Once you have the vartype, you can grab the data directly out of memory and cast it into the proper value.

The kicker, is that null is a memory pointer. Memory pointers take 4 bytes in BYOND. So even if it's null, the re's still 4 bytes hanging around. All you did was trade 4 bytes for 4 bytes and waste some processing time.
It's not RAM you should worry about with BYOND, it's CPU, it's a hog..
In response to A.T.H.K
A.T.H.K wrote:
It's not RAM you should worry about with BYOND, it's CPU, it's a hog..

That sort of mindset is what created the 500MB hogging games that I see constantly everyday. Yes, most of it is from loaded resources. But you have to also factor in the fact that they literally give every mob the same variable. A quest npc has health for instance. It also has money too. And I think when it gets bad enough it bottlenecks too. Which I find odd.

Also, 8Bit, I'd like to know what ways there would be to clean up variables. I hope Lummox can answer whether or not null values truly do hold memory to the program still or if it just becomes a null pointer, not reserving space in the RAM.

If there truly is no way of cleaning it up, do you think it would be hard to have something that does it in the future (not near future -- for Lummox)? It seems interesting to do some memory management. Last time I even got close to playing with pointers was a few months back when I began programming in C.
In response to Xirre
Xirre wrote:
A.T.H.K wrote:
It's not RAM you should worry about with BYOND, it's CPU, it's a hog..

That sort of mindset is what created the 500MB hogging games that I see constantly everyday.

Wat

Yes, most of it is from loaded resources. But you have to also factor in the fact that they literally give every mob the same variable. A quest npc has health for instance. It also has money too.

Don't put them in the same path?

world
mob = /mob/player

mob
player
var
hp = 100
money = 100
npc
var
_500MBvar = "lolol"


You're worried about 500MB of RAM?

Don't offer your clients so much RAM if you're worried.. Or get a proper box with adequate RAM..

500MB isn't really all that much nowadays.

Really though throwing ten people on a box with less RAM than it has isn't a good move from the start, your clients should also have an idea of the usage their games use and buy appropriately, or you should be pushing them to upgrade to a higher plan to ensure quality and performance..
In response to Kozuma3
Kozuma3 wrote:
Xirre wrote:
A.T.H.K wrote:
It's not RAM you should worry about with BYOND, it's CPU, it's a hog..

That sort of mindset is what created the 500MB hogging games that I see constantly everyday.

Wat

Yes, most of it is from loaded resources. But you have to also factor in the fact that they literally give every mob the same variable. A quest npc has health for instance. It also has money too.

Don't put them in the same path?

world
> mob = /mob/player
>
> mob
> player
> var
> hp = 100
> money = 100
> npc
> var
> _500MBvar = "lolol"


Tell that to them, not me. I properly separate my variables, making sure only certain objects/mobs have variables they will need. Lol. Honestly, I was just extremely curious for an instant on this topic because it would be interesting, in my opinion, to learn new ways of efficiency. Who knows, it may open a new door, releasing some minor limitations.

A.T.H.K wrote:
You're worried about 500MB of RAM?

No. This topic isn't about me worrying. It's for knowledge. Nor am I trying to implement this in anything. So quit assuming. I just like to learn more about different things is all.

Don't offer your clients so much RAM if you're worried.. Or get a proper box with adequate RAM..

What?

500MB isn't really all that much nowadays.

You're right. But it is considering I've seen BYOND do crazy things at 1GB RAM. Practice and learn new ways to simplify things and you'll never reach that problem. Not only that, you'll be able to get more out of what you make. Even if it's a small portion.


Really though throwing ten people on a box with less RAM than it has isn't a good move from the start, your clients should also have an idea of the usage their games use and buy appropriately, or you should be pushing them to upgrade to a higher plan to ensure quality and performance..

More assuming. All I read was the first 4 words. When I wrote this, it was intended for single-player games. Not anything that's hosted. The whole point in this post was to discuss whether or not there would be some way to go about freeing up the memory of certain variables when another variable already keeps track of it. That's all.

It has absolutely nothing to do with Shell Server in the slightest. Nor will it ever. Shell Server is as efficient as can be. With occasional crashes from constant shell() calls, it has absolutely no problems.
Short answer: Any var that is not set to its default value will take up memory as a var struct; it's actually going to take up more than 5 bytes, because the Value type itself typically stretches to 8 for alignment purposes, and there's more data in the struct.

So conserving vars by resetting them to their defaults when not in use is a good idea. However, with a var like hp, I'd keep it numeric at all times. If it's reset to 0 and that's its default value, the same savings should be are realized.
I have to amend my answer on this, having looked at the var code in recent months. It appears that var memory, once claimed, is never let go for the life of the object. Turns out it's too much work to compare the var to its default, so DM does the responsible thing and chooses CPU over RAM.
as an addendum: That is not to say that all memory that is claimed is never released. Objects free their memory once released. Lists are a special case here, because lists dynamically hop in and out of memory locations based on a certain reserved size.

My understanding of this is that once a list grows past a certain size, an entirely new region of memory is allocated to accomodate the growing size of the list, and then the memory of the old list is copied into the beginning of the new memory area.

I am uncertain whether the list frees this memory based on when it loses elements.

This basically means that as long as lists exist, they will actually take up more memory than they actually need. And this is a good thing. Otherwise adding things to lists would take a long time.
Lists do free memory when they shrink past a certain point. If a list shrinks below 1/4 of its allocated capacity, it will reallocate. If it shrinks to 0, on the other hand, it will typically release the memory outright.