Memory leaks?

I've built a really epic map now, over the course of 5 years (or from whenever war3 came out). When I started I was really newbish when it came to triggers, and I didn't consider this "memory-leak". I would want to go over the map and make it more effective and close any such leaks I might have.

What kind of triggers should I avoid? Could anyone show me a sample trigger that leaks? Is periodic events the only real concerns when it comes to leaking?


I would believe that the billions of computations a cpu can do each second is more than enough for any computations my map does each second (that is not the millions built into the engine of the game!), but last time I've tried it it lagged pretty severe. I don't know if it was the map or the network, but I'm worried nonetheless.

Memory Leaks are physical memory used by an Application, like warcraft, to hold useless or unreferenced data. I would advise you to read beginner tutorials on jass to have an understanding of what makes maps work and lag, considering if your just new to triggering.
About the periodic events, I think using too much at very small intervals like 0.01 of a second causes lags, I haven't made any maps yet so I wouldn't know much. Goodluck man.

Well, mostly. If your trigger which runs at map init leaks 16 bytes, it's no big deal. If your trigger which runs every time somebody casts storm bolt leaks, it's no big deal.

If your trigger which runs 100 times every second leaks 160 bytes, then the leak is approximately 1,6kb/s. After 2 hours of gameplay you have aquired 7,2*1,6 megabytes of leak. Still not a very big deal, but might matter.

_____________________________________________________________________________


Trigger above leaks a special effect.


___________________________________________________________________________________


Trigger above leaks a location/point.


A point is an object (just like a special effect / unit group / player group ) etc. Everytime you create an object and do not remove/destroy it, it will leak (in the example the object is set to a variable. That way we can destroy it later with the custom script.)

Leaks add up. Some leak a lot more than others. Leaking a timer every .05 seconds for 30 minutes will destroy my framerates, whereas leaking a point for the same amount of time isn't noticeable.

Ok, so it sounds like you're safe from dangerous leaking if you don't leak a lot of timers or points in very short time intervals. That's reassuring to hear.

You shouldn't leak anything, period. Lag can effect some computers differently than others, especially if the connection is bad.

And you're never "safe" from dangerous leaking unless you have no leaks or like, 20 in a game of an hour. Here's a quick anti-leak rundown:

-Are all your handle variables nulled at the end of every function?
-Do you clean all temporary handles (such as special effects, points, etc.)
-Do you clean everything after you've finished using it?
-If you are working in GUI, have you cleaned all your leaks using some form of... well, leak cleaning? (GUI has really bad leaking if you don't use some JASS code to clean it)
-If you are working in JASS, have you cleaned all your created handles with their appropriate destroyer?

I'm not going down the JASS road just yet, (unless I get some experienced folks to work with me as soon as they see the beauty that is my map ;) ), but I'm interested doing what I can with the GUI.

So do you mean that any unit marked as a variable that dies leaks? Every special effect that finishes off? What about a variable that changes value?

When a local or global variable is referenced to a handle (unit, location etc.), the reference count of the handle increases. When the variable is set to something else, the reference count for that handle decreases. If a handle is destroyed, when the reference count is zero that handle index is freed (this is so you don't get a new handle taking the old ones place and being referenced by previous variables).
There is a bug, that locals referencing handles when functions return do not cause the reference count to decrease, even though the referencing variable has gone out of scope. As such, the handle index can never be freed.
This happens internally in GUI, and there's nothing you can do about it with only GUI.
It's not an issue when referencing stuff to globals.

Increasing the handle index causes slowdown to the game, which can be a serious issue if it gets very large.

If you want a more detailed explanation, see this tutorial by PipeDream.