You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Along with Scheduler performance improvements (issue #109 and issue #187 ), knowing which events are scheduled the most and which are taking the most time in simulation is very helpful.
To do this (and not be intrusive), the Scheduler shouldn't be touched. Instead, as events are executed, a separate operation will be called that tracks the following:
Event counts (number of times the event was fired)
Event time (average time and total simulation time taken by the event's main handler)
What we can determine from this is overuse/over-scheduling of an Event, and which Events are consuming the most about of time. Naturally, a good profiler can tell the modeler which event is taking the most amount of time, but knowing how many times it was scheduled is eye-opening for a lot of developers.
This separate operation will be a proxy between the Event and its main handler. It will intercept the call from the Scheduler, start tracking, call the event, then stop tracking and return to the Scheduler.
The text was updated successfully, but these errors were encountered:
ghost
changed the title
Scheduler: Add event hueristics and performance meauring
Scheduler: Add event heuristics and performance meauring
Aug 11, 2020
ghost
changed the title
Scheduler: Add event heuristics and performance meauring
Scheduler: Add event heuristics and performance measuring
Aug 12, 2020
Along with Scheduler performance improvements (issue #109 and issue #187 ), knowing which events are scheduled the most and which are taking the most time in simulation is very helpful.
To do this (and not be intrusive), the Scheduler shouldn't be touched. Instead, as events are executed, a separate operation will be called that tracks the following:
What we can determine from this is overuse/over-scheduling of an Event, and which Events are consuming the most about of time. Naturally, a good profiler can tell the modeler which event is taking the most amount of time, but knowing how many times it was scheduled is eye-opening for a lot of developers.
This separate operation will be a proxy between the Event and its main handler. It will intercept the call from the Scheduler, start tracking, call the event, then stop tracking and return to the Scheduler.
The text was updated successfully, but these errors were encountered: