@kdusr: Hmm, reading the doc (
https://docs.python.org/3.4/library/...tcheckinterval &&
https://docs.python.org/3.4/library/...switchinterval) this should have no bearings on this, as this is single-threaded, and not really subject to any kind of signals (or, really, anything even remotely computationally intensive as far as Python is concerned).
Not a Python wizard, so open to more details, instead of a random "try this" drive-by
.
@handyguy: Those "multiple weeks" stats are usually for 30 minutes of "awake" time each day, so, *one* wakeup per-day, and spending most of its time asleep. And even if you forget those kind of stats, and assume that, say, you can achieve between 24 to 48H of "screen on" time (warning: random number
), that'd be mostly contiguous sessions, with very few sleep/wakeups cycles. Not really applicable to your use case.
The overhead of sleeping/waking up is probably much higher than that all on its own. What takes the cake is toggling WiFi, though, as bringing the radio up is murder for the battery.
I think @ilovejedd ran a bunch of tests a while back checking how long the battery actually lasted with the device just plain asleep, never woken up, you might want to dig that up
.
That was done to test the "deep sleep" (or whatever it's called) feature of some newer Kindles like the latest Oasis, which can optionally do a suspend to disk (-ish, IIRC).