Nulling in GUI

[Vinz]

Does nulling Temps actually count in GUI? I mean, the pointer is replaced when the Temp is next used anyways.

 

[deathismyfriend]

Does nulling Temps actually count in GUI? I mean, the pointer is replaced when the Temp is next used anyways.

Only null at the end of the trigger. You do not need to null every time you use it.

 

[Vinz]

I know, but I heard the var pointer only takes up 4 bytes and does not matter since it is set to something else the next time anyways. Is that true?

 

[deathismyfriend]

I know, but I heard the var pointer only takes up 4 bytes and does not matter since it is set to something else the next time anyways. Is that true?

When not in use for a while it actually leaks a very small amount of memory. Because it is so small it is not required for spells and systems here but it should be nulled IMO.

 

[Tal'Rarity]

I think only unit variables can be nulled in GUI.

 

[Chaosy]

personally I think it's a big waste of effort. The product you gain in comparison is not worth the risk of screwing something up.

But yeah it should save you a few bytes if done correctly.

 

[edo494]

I think only unit variables can be nulled in GUI.

you can null units at very least with GUI.

Yes it will create 4 bytes per referenced object, which is not significant in any way shape or form. But then again, its best to have no leaks whatsoever

 

[Chaosy]

I just want to point out that this is equal to a null.

• Set u = No unit

 

[Dr Super Good]

Nulling is only required for instance arrays. Temporary variables that are shared across multiple triggers that are constantly used do not leak anything. Yes they may lock-down a handle index for a period of time but the amount is very strictly limited and not permanent so not a leak.

Array indices need nulling in instance based systems because there exists a period of time for every session that a maximum number of instances will exist. This could be abnormally, or even absurdly large. Since instance arrays are largely unbounded (anywhere between 0 and 8191 instances can exist in them) you need make sure that no persistent resources are retained in "destroyed" instances so that the maximum period does not cause a persistent leak (since most of the time is not the maximum).

A good example could be a plague on an army early on where each unit affected is given a separate instance. This could reach over 1,000 instances! However after the plague most units are now dead so that the maximum possible plague instances is only like 50-100. Since it never will reach 1,000 (or the chances of it are very low) you can consider it a leak if any resources are persistently held.

 

[Tal'Rarity]

So u doesn't leak however u[1] and u[2]/u[loop] for example can leak?

Are you sure about that?

 

[Dr Super Good]

So u doesn't leak however u[1] and u[2]/u[loop] for example can leak?

In an instance based system where index 1 and 2 may only have been allocated once at the maximum instance period then yes. Since 1 and 2 may never be allocated again they can be considered leaks even though they are still reachable, just they never will be reached for the remainder of the session.

Holding on to a dynamic number of resources for an unknown amount of time when not necessary is not particularly good and should be considered a resource leak, even if nothing is physically leaked. In the case of instances this refers to blocking up handle indices preventing them from being recycled in an instance that no longer exists at a location that may never be used again during a session (although it could be! just might not).

The overhead of nulling in the case of instance destruction is minimal as instances usually have considerable length of life so there really is no excuse not to.

To give you an analogy. Imagine global handle variables as boxes. An array is now a shelf with many boxes. Each box stores just a single piece of paper, a token, to some resources. Changing the contents of the box means returning the old token and placing a new one in it.

If you are using a box to temporarily hold values during computation then you will find that you often change the contents of the box. If you leave a token inside it after computation it gets quickly removed as you find yourself needing to use that box again. Also the number of tokens left in boxes is very small, at most the number of boxes you use in this way. This is what temporary variables do in GUI and why nulling them would just increase overhead for minimal gain.

Instances need to use shelves of boxes. Allocating an instance removes a box form the shelf for use. Deallocating an instance places it back on the shelf for use in the future. If you leave a token inside a box and then deallocate it there is no guarantee that you will ever get that box again to remove the token. Until the token is removed it cannot be used again for other resources even if the resource it was used to access has long since died. This is why you need to null instances before deallocating their storage as part of the destruction process. Since the rate of placing boxes back onto the shelf is low, there is no harm emptying it before hand.

 

[Tal'Rarity]

So does udg_u leak or not?

 

[PurgeandFire]

Leaks aren't always set in stone. DSG is explaining that arrays, when not nulled, can be considered to be leaks.

But what is a leak? We usually refer to a leak as memory that exists, but cannot be referenced and/or is useless. In the case of arrays, there is potential for some memory to be "useless". His analogy about the plague/army thing illustrates that.

As for nulling globals in general: you can if you want, you don't have to (our spells section does not require it). It is a minor leak compared to leaking handles that are undestroyed, and compared to the local variable leak (if locals are left unnulled). Handles can still recycle their handle ID even if globals are pointing to it. All that is leaking is a 4-byte reference. In most cases, it is not worth the effort. Memory is cheap. You may save a couple 100 bytes in the long run, for memory, but you'll end up using more file space just to account for that. It is minor either way, so it comes down to a matter of preference/priorities.

And to answer your question: theoretically, reassigning the temporary variable should allow the reference count memory to be freed, but it depends on (1) whether that is the only reference (2) it depends on how wc3 was coded. It isn't clear. On a theoretical level, you're correct. But it is hard to test such things without watching memory, and who wants to do that? It is trivial.

 

[Tal'Rarity]

Since memory for wc3 usually maxes out at 1.85GB I would prefer to spend a few bytes to null a few bytes.

Also it looks like leaks are transferred from session to session/lobby/chatrooms otherwise how does it continually rise?

 

[Dr Super Good]

Also it looks like leaks are transferred from session to session/lobby/chatrooms otherwise how does it continually rise?

Probably because of where stuff is allocated in memory. It can only free pages that have completely nothing allocated on them. Even if a tiny 1-2 byte structure is allocated on a page it cannot be freed until that structure is freed.

Worse is if the game allocates multiple pages at a time. It then cannot free them until all the pages are empty.

It might also be a file cache. Why re-load something if you loaded it once.

Leaks? Well also possible but I doubt its from gameplay data as otherwise exiting to lobby will leak an entire session worth.

 

[Vinz]

Thanks for the replies.

 

[PurgeandFire]

Since memory for wc3 usually maxes out at 1.85GB I would prefer to spend a few bytes to null a few bytes.

To each his own. When you have an 8 MB limit (for multiplayer), priorities change. Keep in mind that it is an incredibly low amount of memory. Honestly, if you end up getting even 1 MB of memory from reference counts, then you're doing something wrong. That implies that one has gone through 250,000 independent handles. Even at that, you have millions of those you can go through.

I understand your logic though: why waste extra bytes? However, for wc3, one has to become practical. I would rather waste that little bit of memory than bloat my code with unnecessary text. Also, the byte tradeoff isn't equal. You'll spend more bytes in your map to save a lower amount of memory.

Also it looks like leaks are transferred from session to session/lobby/chatrooms otherwise how does it continually rise?

Do you have proof? I'm not trying to accuse you, I am just unable to test it myself and I would like to know whether this is actually true.

 

[Dr Super Good]

I understand your logic though: why waste extra bytes? However, for wc3, one has to become practical. I would rather waste that little bit of memory than bloat my code with unnecessary text. Also, the byte tradeoff isn't equal. You'll spend more bytes in your map to save a lower amount of memory.

Leaking is not so much a problem due to memory, but other undesirable effects. These range from greatly reduced performance all the way to crashes (not OOM). A lot of the code of WC3 uses very slow O(n) style lookups that scale badly (why map loading takes so long) so raising n is not a good idea. Additionally some resources are finite (eg the number of destructible) which once exceeded usually causes a fatal error.

 

[Veritas 117]

Additionally some resources are finite (eg the number of destructible) which once exceeded usually causes a fatal error.

Would you happen to know the maximum number of destructibles? I'm curious to know how close to the limit I may be.

Also, this thread has a lot of great information in it.

 

[Tal'Rarity]

To each his own. When you have an 8 MB limit (for multiplayer), priorities change. Keep in mind that it is an incredibly low amount of memory. Honestly, if you end up getting even 1 MB of memory from reference counts, then you're doing something wrong. That implies that one has gone through 250,000 independent handles. Even at that, you have millions of those you can go through.

I understand your logic though: why waste extra bytes? However, for wc3, one has to become practical. I would rather waste that little bit of memory than bloat my code with unnecessary text. Also, the byte tradeoff isn't equal. You'll spend more bytes in your map to save a lower amount of memory.


Do you have proof? I'm not trying to accuse you, I am just unable to test it myself and I would like to know whether this is actually true.

Trigger/code data barely takes up file-size so it is worth it, check my signature how to "officially" remove the 8mb file size limit by Blizzard and discovered by me and others.

Sadly I don't have any way to show you, yeah I know you aren't trying to accuse me. I have played the Warcraft series since I was young and I know too much about it, yes somehow the leaks or something must travel from session to chatroom/menu to session otherwise the memory wouldn't rise. Though it is also possible that Blizzard's code by default just continually leaks until you restart the game. I am however able to test it and I am 100% sure that one of these idea's is true. Even if I showed you screenshots it wouldn't suffice, I don't have the ability to make video's anymore either. Either you can test it or get someone else to test it because I just can't submit enough evidence. Basically create 1000 units within a minute or less then remake about 5-10 times while beforehand checking your memory in task manager/whatever you use.

Leaking is not so much a problem due to memory, but other undesirable effects. These range from greatly reduced performance all the way to crashes (not OOM). A lot of the code of WC3 uses very slow O(n) style lookups that scale badly (why map loading takes so long) so raising n is not a good idea. Additionally some resources are finite (eg the number of destructible) which once exceeded usually causes a fatal error.

I'd like to know a bit more as well about those finite resources. I kind of figured that myself, it is a old game.