Currently, the runner pulls in updates as agressively as possible (when using run(bot)). While this leads to the highest possible responsiveness of the bot, it also causes more network traffic than if there was a short delay between the calls. Ideally, we would:
Measure the throughput dynamically, averaging over the last 15 calls or so
Compute how much time it would take to fill up an array of 100 updates
Add a config option that lets users specify if they want responsiveness or few network calls, as a value between 0 and 1
Dynamically add delays between the calls when the runner simply idles, waiting for more updates to accumulate before they are being fetched
Naturally, this would have to be done in a way that certain interruption in traffic do not lead to too long idle phases. In other words, this would have to be done in a way such that responsiveness does not suddenly drop arbitrarily low because the runner is trying to wait for three hours until the update array is filled.
Currently, the runner pulls in updates as agressively as possible (when using
run(bot)). While this leads to the highest possible responsiveness of the bot, it also causes more network traffic than if there was a short delay between the calls. Ideally, we would:0and1Naturally, this would have to be done in a way that certain interruption in traffic do not lead to too long idle phases. In other words, this would have to be done in a way such that responsiveness does not suddenly drop arbitrarily low because the runner is trying to wait for three hours until the update array is filled.