kasbah
commented
5 years ago You could also give PyPy another go, though it actually seemed slower with Python 3.5 on the Raspberry Pi when I tried it.
Book loading is slow, and (from the privileged position of hindsight) one rather ingrained inefficiency is the loading of the entire library of entire books, but it's probably a significant job to rearchitect this to loading only the first/current pages and doing the rest largely on demand. (And while there, it'd be nice to address print/formatted page numbering issues like #134, and keep the text/braille correspondence around for features like #188.)
I played around with several different ways of loading books. It would be fairly straight-forward not to load entire books up front but you have to give up having the page number summary in the library menu or find a quicker way to get the total number of pages without converting an entire book.
Some aspect of the UI's main loop is inefficient and the UI process is often top by CPU use when idle. This is probably an artefact of polling the firmware for button status, and may go away if we switched to interrupts.
A quick fix is probably to increase the sleep time here: https://github.com/Bristol-Braille/canute-ui/blob/557f1dd3f23acfd2bab5a8c10a704ab533015727/ui/main.py#L118
Meta-issue to collect these observations & thoughts; not going to try quantifying what is/isn't acceptable, except to opine that eliminating redundant book loading work (#182) isn't sufficient to call this fixed.
Booting the OS is slow, but that's already part of #23.
Python is slow on a Pi Zero. As quantified when crudely restarting the UI to refresh the library in #183, just getting to the end of module loading takes ~8 seconds. Bytecode caching is working correctly.
Book loading is slow, and (from the privileged position of hindsight) one rather ingrained inefficiency is the loading of the entire library of entire books, but it's probably a significant job to rearchitect this to loading only the first/current pages and doing the rest largely on demand. (And while there, it'd be nice to address print/formatted page numbering issues like #134, and keep the text/braille correspondence around for features like #188.)
Some aspect of the UI's main loop is inefficient and the UI process is often top by CPU use when idle. This is probably an artefact of polling the firmware for button status, and may go away if we switched to interrupts. Another factor may be that every state change spawns four tasks, but perhaps async tasks are cheap.
Firmware issues are tracked elsewhere, but see #204 and: