Direct links to source: https://bitbucket.org/leif_theden/pyglet/src/be965fbe37512a2bc207990f9a148f12942733a2/pyglet/clock.py?at=heap_clock https://bitbucket.org/leif_theden/pyglet/src/be965fbe37512a2bc207990f9a148f12942733a2/tests/unit/test_clock.py?at=heap_clock
On Saturday, October 24, 2015 at 4:39:04 PM UTC-5, Leif Theden wrote: > > 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.
