HomeUser Control Panel (unavailable in archive)ForumsTutorialsArt GalleryResourcesMaps

[?]About Leak

06-17-2004, 10:13 AM#1
danny760311
When you destroy a handle, will the sub-handles be destroied??

For example, if Trigger T has event E, condition C, action A. When you call DestroyTrigger(T), will E,C, and A be destroyed??

Similar to above, will destroying leaderboard(multipleboard) destroy leaderboarditem(multiboarditem)? Will destroying quest destroy questitem? Will destroying dialog destroy dialogbutton?
06-18-2004, 12:05 PM#2
Cubasis
Yes and No.

Destroying a trigger destroys the events and conditions. But the actions need to be manually removed from the trigger for complete leak-freeness. Which can be ignored, as it's not all-that horrible of a leak. But if you do want to avoid it, you have to get the triggeraction returned by TriggerAddAction, store it, then later use TriggerRemoveAction, passing in this triggeraction, to remove the action properly. You can not just do TriggerClearActions.

With multiboards, you need to ReleaseItem's each item that you "get" (with GetMultiboardItem()).

I am sure that destroying a Quest destroys its Quest Items. As at a quick glance I can't see other functions to do that.

~Cubasis
06-18-2004, 03:55 PM#3
danny760311
Quote:
Destroying a trigger destroys the events and conditions. But the actions need to be manually removed from the trigger for complete leak-freeness.

Well, I've just made a test of leak yesterday:

1st, create 300,000 locations and leak them, there's a significant delay while leaving the game...

2nd, run:
local trigger T = CreateTrigger()
call TriggerAddAction( T, function DummyAction )
call DestroyTrigger()

300,000 times, and there's NO delay while leaving the game...

So I wonder whether Actions leak...

I've also test Leaderboard by this method, it doesn't leak items, I think..
06-18-2004, 04:38 PM#4
Cubasis
Firstly,

I reccomend ya to watch the differences in Memory usages in the Task Manager for better tests.

also, I assumed you were talking about Multiboards.... as you can't work with Leaderboard Items, only Multiboard "items". And then you "would" only leak items that you get using GetMultiboardItem.

~Cubasis
06-22-2004, 05:31 AM#5
danny760311
I agree with you. But how do you explain why 300,000 triggeractions don't even cause a leave-game-delay but locations do? How come do they leak but don't cause any delay?_? If it DOES leak but causes so little delay then we can just ignore the "leak" can't we?
06-22-2004, 05:32 AM#6
danny760311
By the way, how to destroy a gamecache?
06-22-2004, 01:18 PM#7
Cubasis
Well, you can flush it. There isn't really a need for destroying it, that clears everything in it.

I'll do some more tests on Trigger-leaks, who knows, maybe my tests were flawed.

~Cubasis
07-06-2004, 11:46 PM#8
Starcraftfreak
What about calling TriggerClearActions(t)? I haven't tested it, but if that function works as the name suggests it would save a lot of code since you don't need to take care for the handles of the triggeractions. It would be awesome.
To destroy a trigger to make sure it doesn't leak you call:
Code:
call TriggerClearActions(t)
call DestroyTrigger(t)
07-07-2004, 08:23 AM#9
KaTTaNa
I don't think TriggerRemoveAction helps anything.
I tried this:
Code:
function Actions takes nothing returns nothing
    
endfunction

function Trig_Untitled_Trigger_001_Actions takes nothing returns nothing
    local trigger trg = CreateTrigger()
    local triggeraction a = TriggerAddAction(trg, function Actions)
    call TriggerRemoveAction(trg, a)
    call DestroyTrigger(trg)
    if ( a == null ) then
        call DisplayTextToForce(GetPlayersAll(), "a is null")
    else
        call DisplayTextToForce(GetPlayersAll(), "a is not null")
    endif
endfunction
And it displays "a is not null", so I doubt removing triggeractions will do any good.
07-07-2004, 12:36 PM#10
AIAndy
That test does not show anything as passing a to any function/native does not change the content of a (pass by value) so of course after a being set to a value it is not null in the end of the function despite being passed to TriggerRemoveAction.
07-18-2004, 12:09 PM#11
jmoritz
My test setup did a loop 30.000 times when a player types "test1". The code in the function:
Code:
function Trig_Untitled_Trigger_001_Actions takes nothing returns nothing
  local trigger t
  local triggeraction a
  local triggercondition c
  local event e
  local integer j = 0

    loop
      exitwhen j > 30000

      set t = CreateTrigger()
//      set e = TriggerRegisterPlayerChatEvent( t, Player(0), "foo", true )
//      set c = TriggerAddCondition( t, Condition(function condfunc) )
//      set a = TriggerAddAction(t, function actionfunc)
//      call TriggerRemoveCondition(t, c)
//      call TriggerRemoveAction(t, a)
      call DestroyTrigger(t)

      set j = j + 1
    endloop

endfunction
The results, in MB added after 1 run, and MB every additional run after the first, as reported by windows task manager in WinXP:

A) CreateTrigger, DestroyTrigger: 14 MB, negligible
B) event: 13 MB, 400 KB going down to 4 KB, total 1MB
C) add cond: 14 MB, 120 KB going down to 4 KB, total 400 KB
D) add&rem cond: 14 MB, negligible
E) add action: 14 MB, 4 to 5 MB
F) add&rem action: 13 MB, negligible
G) add action, add&rem cond: 12 MB, 2.5 to 3 MB
H) add&rem action, add&rem cond: 12 MB, negligible
I) just the trigger, wait every 3000 loops: 4 MB, negligible

The small differences in the first run (12,13,14 MB) are probably because of animations, chat text etc. It looks a lot like triggers are alocated a lot of memory, and events and conditions are placed in this allocated memory, so they don't take any additional. Actions however, are allocated new memory: roughly 100 bytes per action. Interesting is the decrease in memory leak in case G compared to E. Maybe conditions and actions use each other's memory?

Conclusion: triggers leak a lot, but they are recycled whenever a trigger finishes or sleeps. Actions and conditions don't leak, if cleaned up. Events leak a bit, but not enough to ever worry about it.

Further research ideas: how does having thousands of triggers active at the same time affect performance? Is it possible to have 200 units in-game, all with 5 triggers using unit-specific events?