If the new clock works fine, we can probably pull it into the main branch for 1.3.x. So make a pull request when you feel you are ready.
I did know you already did improvements in your fork. Just did not have time yet to pull those in. Rob Op maandag 26 oktober 2015 05:09:50 UTC+1 schreef Benjamin Moran: > > Tested on a Linux box with Python 3.5. No issues. I'll give it another try > with your recent update. > > It may be a relatively small improvement, but many small improvements add > up! > > > 2015年10月26日月曜日 11時51分43秒 UTC+9 Leif Theden: >> >> 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 http://groups.google.com/group/pyglet-users. For more options, visit https://groups.google.com/d/optout.
