Unit creation and permanent leak

[Ardenian]

I recently read in Flux's Dummy Recycler that creating units causes a memory usage ( == permanent leak ?).

I am lot worried about the performance of my own map project now.
My map basically uses units everywhere, as everything and there are dynamically created and destroyed.

I would like to know, would a recycler for these units be a highly recommended issue ?
Does dynamic unit creation cause leaks/frame rate drop ?

It would not only require me to re-write my entire script ( 1200 lines),
but also to edit all models I use.

 

[Chaosy]

I have never heard of such a leak.

 

[Ardenian]

I am not sure whether it is a 'leak'.

Flux says in his resource description:

Why is recycling a unit important?
//      Because creating a unit is is one of the slowest function in the game
//      and it will always leave a permanent tiny bit of memory (0.04 KB).

 

[Flux]

It was written in IcemanBo's tutorial
http://www.hiveworkshop.com/forums/trigger-gui-editor-tutorials-279/memory-leaks-263410/
And then there's also this thread
http://www.hiveworkshop.com/forums/lab-715/widget-memory-footprint-277476/

 

[Ardenian]

So in the best case I avoid dynamically creation ?

As example, I would periodically create 400 units at least, that would be 16 KB, each time.

 

[BPower]

It's true, creating units is a relative heavy operation.
I extra said relative, because the speed difference is significant in stress tests
and rather not important in a compiled play-able map.

Rule of thumb: Taking care of better performance is important if you encounter a performance problem.

Eventually units create a permanent leak in data, but then it's really small.
In past patches unit recyclers has a greater meaning, because there the leak was
more significant.

In my opinion using a dummy recycle can be useful, but it's not a must have.
It depends also a bit on your map. For example if you need tons of dummies
over a game season a dummy recycler absolutly makes sense.

 

[IcemanBo]

I state that it leaks 0.04kb, but it was not the result from my own testing, but Maker told me iirc.
I don't have access to the testing back then though.

HappyTauren has some other numbers as you can see.

Though what is sure that it perma leaks.
An exact memory occupation is not so easy to prove with wc3, so I won't say mine is right and his is wrong, or vise versa.
It would need some detailed analysis of old testing and these newer tests to make a comparison.

 

[Ardenian]

The main problem why I rather would like to avoid writing is how my map is concepted.
It would require me to merge many models to make perfect use of the dummy recycler.

However, I think it is a useful addition, I don't need to re-create units I already have/had.

Thank you guys!

 

[HappyTauren]

Well, the reason you'd REALLY want a dummy recycler in a game that's not meant to go on for hours is essentially that you can create the number of dummy units requires for a few instances of your spell, and then tuck them away, and then use a function to utilize them whenever you need them, without dynamically creating them UNLESS NECESSARY.

For example, if you're making an AoS and there's only ever going to be one instance of a certain spell, you're safe off just creating the number of dummies you'll need at max at the start of the game, and creating any new ones only if absolutely necessary, this should help a lot with performance, but in terms of leakage, it's a 20-60 minute game, it won't really matter that much.

Of course, if you use generic dummy units, this all changes, but you can still pre-create a bunch of them and use them with the same principle - recycle if possible, create if necessary.

And no, you don't need to change your map at all. You don't have to merge dummy units at all, you can just use a generic recycler that will let you call CreateUnitEx with the same arguments as the original function, and you get whatever type you wanted, if it was possible to recycle, great, if not, no biggie, you'll still get your unit.

 

[Ardenian]

recycle if possible, create if necessary.

Aight, thank you, then I follow this rule!

 

[EdgeOfChaos]

Yes, it is true, but it should not be a concern unless your unit count is in the millions.

 

[Zwiebelchen]

How about you tell us how many units exactly you are creating dynamically?

In the case of using a dummy or unit recycler or not, numbers matter.


A rule of thumb, imho:
Missile systems should recycle dummies. If you are just respawning "real" units, not using a recycler for that is mostly fine.

 

[Ardenian]

I create, estimated, around 100000 units per game instance.

I am going to use a recycler, else that's inefficient, isn't it ?

 

[Dr Super Good]

Unit leaks do not cause performance problems as far as I am aware. They have been attributed to crashes but that was only after absolutely excessive numbers of units were created and destroyed.

I would only think of looking into unit recycling if you actually have a problem or if your map some how gets through over 10,000 units per session (which no good map ever should, that is a lot of units).

Unit creation does have overhead due to the displacer, similar to SetUnitPosition does. Recycling helps minimize this. Many abilities can get away with having a single dummy unit created at their first cast and then recycled subsequently. Multiple abilities can share a single dummy unit to do all their casting work making it even more efficient. The dummy must be a ward or whatever is required to not have to turn and cast.

Projectile recycling can be very efficient as well. Old systems for such used generic invisible dummy models with the desired model attached as a special effect to it. This not only allowed one some control over rotation through animations but also allowed one to recycle these generic dummy units as much as one desired.