Difference between revisions of "User:DavidJCobb/Stack dumping"

m
CONFIRMED: RegisterForSingleUpdate(x) creates a new stack in x seconds, rather than creating a new stack immediately and suspending it for x seconds. Important distinction, that.
imported>DavidJCobb
imported>DavidJCobb
m (CONFIRMED: RegisterForSingleUpdate(x) creates a new stack in x seconds, rather than creating a new stack immediately and suspending it for x seconds. Important distinction, that.)
Line 17: Line 17:
== Specific methods to minimize stack dumping ==
== Specific methods to minimize stack dumping ==
*There are a number of events that can rapidly generate suspended stacks, because they can occur several times in a short period (such that several calls to your event handlers are queued). If you must listen to these events, then minimize the length of your event handlers, so that the resulting stacks are executed as quickly as possible.
*There are a number of events that can rapidly generate suspended stacks, because they can occur several times in a short period (such that several calls to your event handlers are queued). If you must listen to these events, then minimize the length of your event handlers, so that the resulting stacks are executed as quickly as possible.
** One way to do this is to have the event handlers [[RegisterForSingleUpdate - Form|RegisterForSingleUpdate(''n'')]], and do your actual processing in an [[OnUpdate - Form|OnUpdate()]] event.
*** OnUpdate() is called by the game engine. Using it will generate a new call stack.
*** If ''x'' events occur within ''n'' seconds of each other, you will process all of those events just one time.
** Don't use Utility.Wait() in these event handlers. It will by definition make your event handlers take longer to execute.
** Don't use Utility.Wait() in these event handlers. It will by definition make your event handlers take longer to execute.
** Minimize the amount of times you access shared resources (such as the player), in order to shorten your event handler's overall execution time.
** Minimize the amount of times you access shared resources (such as the player), in order to shorten your event handler's overall execution time.
*** Remember that your own resources can be shared. If you have a magic effect that coordinates itself via a quest, anyone with that magic effect will be sharing that quest.
*** Remember that your own resources can be shared. If you have a magic effect that coordinates itself via a quest, anyone with that magic effect will be sharing that quest.
** You can "eat" some of the stacks by having your event handlers [[RegisterForSingleUpdate - Form|RegisterForSingleUpdate(''n'')]], and doing your actual processing in an [[OnUpdate - Form|OnUpdate()]] event. If ''x'' events occur within ''n'' seconds of each other, you'll process all of those events just one time.
*** Effectively, those ''x'' events will register for an update and return immediately, clearing ''x'' stacks out of memory. Then, in ''n'' seconds, one new stack will be created to do your processing.


=== Events that can trigger large numbers of suspended stacks ===
=== Events that can trigger large numbers of suspended stacks ===
Line 41: Line 40:
**If this one is the case, then you would not be able to use update events to minimize generated stacks. Like, I seriously doubt it, but AFAIK this sort of thing is documented ''so little.''
**If this one is the case, then you would not be able to use update events to minimize generated stacks. Like, I seriously doubt it, but AFAIK this sort of thing is documented ''so little.''
*'''Test procedure:''' RegisterForSingleUpdate(20.0), and then DumpPapyrusStacks using the debug console. See if an OnUpdate stack is dumped.
*'''Test procedure:''' RegisterForSingleUpdate(20.0), and then DumpPapyrusStacks using the debug console. See if an OnUpdate stack is dumped.
== Miscellaneous facts ==
* RegisterForSingleUpdate(''n'') does ''not'' create a stack and suspend it for ''n'' seconds. I have confirmed this experimentally.
Anonymous user