Greetings! In response to a conversation in another thread, I've put together some changes to the pyglet Clock that offer some performance benefits between 25% - 80% during use based on my benchmarks. This clock doesn't change the API or behavior of the Clock and is a 'drop in replacement'.
Here's the other thread: https://groups.google.com/forum/#!topic/pyglet-users/59IfchOecRY For this topic, I'll outline a couple terms and ideas. For the purposes of this post: - "clock" refers to the pyglet Clock class. - "event" means something that has been scheduled - "interval" and "delayed" events, scheduled with Clock.schedule_once, Clock.schedule_interval, and Clock.schedule_interval_soft are impacted - "every tick" items, scheduled with Clock.schedule are unaffected - When I mention "scheduled events", I will be referring to delayed and interval events, not "every tick" events - "soft scheduling" is a mechanism pyglet uses to distribute interval events over time without executing them all at once, even if they were scheduled at the same time The purpose of changing the implementation of the Clock was motivated by using cProfile to research bottlenecks with pyglet. I noticed that list sorting was impacting performance, and set out to create a replacement heap-based clock. While it may be difficult to notice any gains from the changes in use, it may make pyglet more suitable for using many more scheduled events than was previously available. Just from my own experimentation, significant gains come from scheduling over 200 events. The current Clock maintains a list of events that are to be executed in sorted order. The overhead for maintaining sorted order can be quite high, especially if there are several 100's of events or a lot of scheduling/unscheduling going on. This heap-based clock implementation offers much faster scheduling and unscheduling of interval & delayed events because it don't sort the list. Events that execute each frame/tick are unaffected. The only drawback from this heap clock is that 'soft scheduling' is impacted. By my benchmarks, it typically executes at the same speed or slower as the sorted-list Clock (the one in use now). Soft-scheduling requires a sorted list of events to correctly find a free spot in the schedule so that several events do not overlap and create usage spikes, so the heap-clock has to create a sorted copy of the event queue. Perhaps another mechanism for soft scheduling can be used, however, I have not investigated alternative methods. Even though soft scheduling is impacted, I believe that it is not used often enough in the real world to create a situation where it will negatively affect gains made in other parts of Clock. The changes have been tested against the standard test suite, and I've used a few pyglet apps/games and they seemed to run fine, so I don't see any major issues. I invite anyone to check out the changes and play with it. In summary: - + faster scheduling and unscheduling of events - + faster processing of scheduled events - - slower soft scheduling of events For anyone interested, here is a link to my bitbucket repo with the clock changes: https://bitbucket.org/leif_theden/pyglet/branch/heap_clock Thank you! -- You received this message because you are subscribed to the Google Groups "pyglet-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/pyglet-users. For more options, visit https://groups.google.com/d/optout.
