I almost forgot about this. Added it to the roadmap of 1.3: https://bitbucket.org/pyglet/pyglet/wiki/Roadmap
Rob On 6 June 2016 at 06:57, Benjamin Moran <[email protected]> wrote: > Sorry to bump up this thread after all of this time, but I was curious if > there were any issues with getting this merged. > > On Monday, October 26, 2015 at 11:51:43 AM UTC+9, Leif Theden wrote: >> >> Great suggestion, Petr. I made the changes that you suggested, and got a >> 8-10% speed increase for my synthetic benchmarks. Salvakiya, I'm not sure >> why a heap based scheduler was used in the past. Perhaps the benefit was >> never thought to be good enough to justify rewriting the existing >> scheduler. This change that I'm proposing is just an incremental boost, >> not really one that is drastic. A 40% increase in performance in the >> scheduler doesn't mean much if the scheduler is 10% of the overall CPU >> use. Anyway, I'll need to do more benchmarks to see how it goes with >> real-world use. >> >> So... don't get your hopes up too much about fixing performance issues. >> Pyglet's bottlenecks are still graphics related, and will take care to make >> a quick program. >> >> I've updated my branch. >> >> On Sunday, October 25, 2015 at 4:00:53 AM UTC-5, Petr Viktorin wrote: >>> >>> On Sat, Oct 24, 2015 at 11:39 PM, Leif Theden <[email protected]> >>> 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'. >>> > >>> [...] >>> > >>> > 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. >>> >>> Hello, >>> I haven't studied the code in detail, but I'd like to point out that: >>> 1. Every sorted list is also a heap [0] >>> 2. Python's sorting algorithm is very good at lists that are "almost" >>> sorted (i.e. a few elements/subsequences out of place) [1] >>> >>> So, for soft scheduling you might want to sort the list, insert the >>> event, and then leave the list sorted. This would make the next soft >>> schedule faster, as long as intervening heapq operations don't shuffle >>> the list *completely*. >>> >>> I think it'd be worth exploring but haven't tested/benchmarked it >>> myself. >>> >>> >>> [0] https://docs.python.org/3/library/heapq.html : "heap.sort() >>> maintains the heap invariant!" >>> [1] https://hg.python.org/cpython/file/3.5/Objects/listsort.txt : >>> "3sort", "%sort" >>> >> -- > 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 https://groups.google.com/group/pyglet-users. > > For more options, visit https://groups.google.com/d/optout. > -- 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 https://groups.google.com/group/pyglet-users. For more options, visit https://groups.google.com/d/optout.
