Summons leak?

[Kino]

So Ive heard that unit creation causes leaks.
Does this count summoned abilities as well?

 

[TriggerHappy]

>> So Ive heard that unit creation causes leaks.

It doesn't.

The location you create them at however probably does, so you need to remove that.

 

[WaterKnight]

http://www.hiveworkshop.com/forums/members/dr+super+good/

claims units would be not completely removable. So why would this not include summons.

 

[PurgeandFire]

Well, the unit leak has been a rumor that spread around for quite some time (it did actually exist around patch 1.24):
http://www.thehelper.net/threads/be-warned-theres-still-a-memory-leak-in-frozen-throne.132644/

But Blizzard made an undocumented change that either reduced or removed that issue. Bribe ran some tests a few years ago on it.. so did I. But tbh, I don't even remember what the results were. It was assumed for quite a while that the unit leak still existed (and perhaps it does). However, no one has provided a *proper* test map of it.

When I tested it a month or so ago, the memory seemed to climb a little but after a while it dropped and didn't really go beyond that. But my testing wasn't thorough/documented or anything, so I can't really make any conclusions from that. We just need someone to make a legitimate test and post it in the lab.

The reason why it is annoying to test is that you have to test for all different cases (1) unit is killed [corpse] (2) unit is killed [exploded/no corpse] (3) unit is removed (4) killed, does not decay/does not raise.. etc. whatever else there is.

 

[Kino]

Intresting.

Does anyone know how severe this purported leak is? If so should I really bother about it?

 

[TriggerHappy]

Intresting.

Does anyone know how severe this purported leak is? If so should I really bother about it?

I wouldn't worry about it.

 

[WaterKnight]

In emergency cases, units might be recycled. I am more worried about the string leak and limitations.

 

[Maker]

The unit leak, if it exits, is 40 bytes for normal units and 44 bytes for heroes. That is what I got from my tests. So even 100 000 units won't matter much.

 

[Kino]

Well thanks guys.
I was worried for abit that there was major issue Ive never known about.

 

[Dr Super Good]

Yes units do leak. You can see a clear increase in memory usage over time by running a unit create and remove loop with a low period.

It is unclear if Warcraft III runs some sort of garbage collection pass when running out of resources which may or may not clean up these leaks, however I doubt it has anything so cleaver programmed into it.

It also appears the leak is just memory and not resource related. As such there is not a noticeable decrease in performance unlike string and handle leaks.

The number of units needed to leak for there to be a performance impact is in the order of tens of thousands if not hundreds of thousands. Maps that abuse such unit numbers will likely have other performance problems. It is a non-issue for most maps as even heavy duty zombie survival maps like SWAT Aftermath only get through 6,000 odd units over a multi-hour session.

That said it can become a problem on old computers which are running on very tight memory. As it is, todays complex map systems already push the game far beyond its requirements and unit leaks can be the straw that brakes the camel's back in this case. Although there is no sensible substitution for letting units fight and die, you can avoid this leak by recycling units that are removed by triggers but a unit of the same type will be required later.

Best example would be a creep spawn system which is area based so that only creeps near players are active to conserve resources. Instead of removing the creeps when the player leaves the area just to recreate them when the player comes back, you could hide them and move them near a corner of the map and when the player enters the area move them back and unhide them.

 

[PurgeandFire]

Yes units do leak. You can see a clear increase in memory usage over time by running a unit create and remove loop with a low period.

When did you test it and how?

When I tested it a month or so ago, the memory seemed to climb a little but after a while it dropped and didn't really go beyond that. But my testing wasn't thorough/documented or anything, so I can't really make any conclusions from that. We just need someone to make a legitimate test and post it in the lab.

 

[Maker]

Memory consumption just keeps on increasing.

function looping takes nothing returns nothing
    local integer i = 1
    //local unit u
    loop
        exitwhen i == 0
        call RemoveUnit(CreateUnit(Player(15), 'hfoo', 0, 0, 0))
        //set u = CreateUnit(Player(15), 'hfoo', 0, 0, 0)
        //call UnitApplyTimedLife(u, 1, 0.01)
        //call UnitApplyTimedLife(CreateUnit(Player(15), 'hfoo', 0, 0, 0), 1, 0.01)
        set udg_k = udg_k + 1
        set i = i - 1
    //set u = null
    endloop
endfunction

function Trig_Untitled_Trigger_001_Actions takes nothing returns nothing
    if udg_i == 0 then
        set udg_i = 1
        call BJDebugMsg("start")
        call TimerStart(udg_tmr, 0.01, true, function looping)
    else
        set udg_i = 0
        call BJDebugMsg("stop")
        call BJDebugMsg(I2S(udg_k))
        call PauseTimer(udg_tmr)
    endif
endfunction

//===========================================================================
function InitTrig_Untitled_Trigger_001 takes nothing returns nothing
    local unit u
    set gg_trg_Untitled_Trigger_001 = CreateTrigger(  )
    set u = CreateUnit(Player(15), 'hfoo', 0, 0, 0)
    call UnitApplyTimedLife(u, 1, 0.01)
    call TriggerRegisterPlayerEventEndCinematic( gg_trg_Untitled_Trigger_001, Player(0) )
    call TriggerAddAction( gg_trg_Untitled_Trigger_001, function Trig_Untitled_Trigger_001_Actions )
    set u = null
endfunction

 

[PurgeandFire]

I tried similar code (0.001 period tho) left for 93.861 seconds (equivalent of 93861 units) and it climbed up about ~10,000 K or so, then I pressed ESC to stop it. I went afk for a little and then it dropped down by a large amount to a stable level. I'll post my code tmrw, maybe it is an issue on my side.

 

[Maker]

First 20 000 units -> +3 MB
Next 40 000 units -> +1 MB
Next 37 000 units -> No increase
Next 25 000 units -> +1 MB
Next 18 000 units -> No increase
Next 9 000 units -> No increase

Then I did shorter burts of 1000 units and there was no increase.

 

[best_player_88]

1) Allways remove the location where you create a unit. not doing so causes lags and maybe even game crush.
2) Having planty of units in the same map will cause lag, even if they aren't fighting right now. If each player among 12 players went Mass Necromancers and have each of them cast raise dead, the game would crush, this was determent by a member of this forum who told that to me arround 4 years ago (I can't remember who it were who determent that but if my memeory recalls, it was a forum owner).
3) Having a unit with Reincarnicaton removed while inside the Reincarnication animtion will cause the unit to sustain its food used as if it was still in the game, this is not fixable even if you used "trigger - make food usage off for the unit" as the unit will still take extra food upon removal fromt he map using "trigger - remove unit"

Those three are the unit creation bugs I ever have encounter during my map making so far.

 

[PurgeandFire]

First 20 000 units -> +3 MB
Next 40 000 units -> +1 MB
Next 37 000 units -> No increase
Next 25 000 units -> +1 MB
Next 18 000 units -> No increase
Next 9 000 units -> No increase

Then I did shorter burts of 1000 units and there was no increase.

Did the memory ever drop for you? e.g. after some period of time (wait a minute or two)

Although, I also experienced the little moments where there was no real increase, just bouncing around relatively the same memory. This leads me to believe that there is some recycling/cleaning done internally. Otherwise it would constantly increase.

 

[Maker]

If I remember correctly, during the "no increase" creations, the memory increased but then decreased back to what it was when I stopped creating units.

I kept a one minute break every time to let it "stabilize" or whatever, but the memory consumption didn't change much at all during that time.

 

[Dr Super Good]

What memory were you measuring? Working Set, for example, only shows the memory which is very recently and almost continuously used. Memory leaks only show up on the Working Set if they share pages with non-leaked objects that are in heavy use. Virtual Memory size, on the other hand, shows how much physical address space the process has allocated.

Especially if you are creating units in a loop, you may find entire pages are leaking that fall off the Working Set. Pages not in the Working Set will be paged out more readily than pages in the Working Set of at least 1 process.

 

[PurgeandFire]

What memory were you measuring? Working Set, for example, only shows the memory which is very recently and almost continuously used. Memory leaks only show up on the Working Set if they share pages with non-leaked objects that are in heavy use. Virtual Memory size, on the other hand, shows how much physical address space the process has allocated.

Especially if you are creating units in a loop, you may find entire pages are leaking that fall off the Working Set. Pages not in the Working Set will be paged out more readily than pages in the Working Set of at least 1 process.

Commit, Working Set, and Private memory all went up after creating the units. Eventually they all went down.

And I created units again and they went up and down again. Here is the test map if you have wc3 still installed:
http://www.hiveworkshop.com/forums/pastebin.php?id=yri9rw
Press ESC to create, ESC to stop. Time elapsed will show. Press ESC again to create, so forth...

Maybe I made a mistake in my code. But I left it on for about 111 seconds (about 111,000 units) and it actually jumped down in memory use while the units were still being created. Subsequent tests never got the commit memory above ~140k. It remained relatively static from that point on. And I know the units were still being created because the fps meter/CPU was still high (until I stopped the timer), and the food used was bouncing around occasionally.

Tested on Windows 7.