Repository navigation
RFC: Optimized heap queue implementation for uasyncio #2219
Description
Switch uasyncio to wrap-around time source like utime.ticks_ms(), as required for baremetal ports, requires changing to the comparison done in uheapq module - it should use partial ordering definable for modular arithmetic (ring math object). So, that requires changing uheapq anyway, and I currently have adhoc changes for that coded.
Besides this must-have feature, there're also change to optimize:
- Pre-allocate queue of some size.
- Avoid constant packing and unpacking of tuples as done now.
So, that actually calls for introduction of adhoc heap queue class implementation for uasyncio. The main question is how to implement it - I consider turning current moduheapq.c into header with poor-man's templating implementation to teach it working with different data structures. Any objections?
After this changes, there will be (in a common case) the only remaining source of memory traffic for uasyncio usage - constant generator creation from yield from.
Activity
pfalcon commentedon Jul 3, 2016
For reference: pfalcon/pycopy@75de07a
pfalcon commentedon Nov 10, 2016
@dpgeorge : So, considering current situation and backlog, I'd rather proceed with step by step changes, and merge change in the previous comment largely as is (after required clean up of course). This will allow to switch unix implementation and test it well, and uasyncio.core (I/O-less) can be used on esp8266 for testing too. Let me know if there're any objections.
dpgeorge commentedon Nov 11, 2016
From inspection of that patch it seems that it adds extra args to existing heapq methods, and so retains backwards compatibility. If so then +1 to merge.
pfalcon commentedon Nov 11, 2016
@dpgeorge : Yes, sure, backwards compatibility is retained. The only concern is that later it may need to changed again, then again, and again. But as it involves many moving parts, we'd better really do it like that, step by step, without trying to arrive at a final destination right away. So, some churn would be expected.
pfalcon commentedon Nov 11, 2016
Refactored and merged as 0cbc072.
Merge pull request micropython#2219 from arturo182/IS25LP128F