CP performance decrease since 5.3

[dunkmann00]

When working with the latest beta (5.4.0 Beta 0), it seems like CP is running a little slower than it was in 5.3.0.

Code to test:

import time
start = time.monotonic()
for _ in range(1000000):
    pass
print("Time: {}".format(time.monotonic()-start))

Output (ran on an itsybitsy m4 express):
Version 5.3.0: 4.784 seconds
Version 5.4.0 Beta 0: 9.219 seconds

Can anyone else reproduce this?

[tannewt]

This is expected because we now call the background tasks more than we need to. This is because we have to always run them in case we sleep afterwards.

@jepler prototyped a background task list here: #2879

[dunkmann00]

I see. I stumbled across this while trying to loop through setting NeoPixel code that was working better on the older version.

Is this newer way better? Or just improves background task handling while losing some of the overall speed? (I don't know much (if any) about the background tasks in CP, so to me it just seems like a net negative, but that is probably just due to my ignorance)

[kevinjwalters]

This sounds like it's related to low power features mentioned in https://github.com/adafruit/circuitpython/releases/tag/5.4.0-beta.0 ? If that's the case, is there an argument and possibility of having the programmer explicitly choose and enable that feature in code.py or boot.py to reduce the overhead on the majority of full power applications? Or is #2879 effectively an automatic version of this?

[dhalbert]

We hope and expect to restore the lost performance by the time this comes out of beta.

[tannewt]

The goal is to be better than we were prior to the low power change. Before we waited 1ms between background task runs. Ideally with the new implementation we'll have a single lightweight check that enables us to do the background work as needed. This will mean we can be more responsive in the background while reducing the check cost.

[kevinjwalters]

There's a 19x slowdown reported in https://forums.adafruit.com/viewtopic.php?f=58&t=165699 for 5.4.0-beta.0. The code is in the post so that might be useful as a test case for any changes here.

[kevinjwalters]

@dhalbert was involved in this one but to bring things together there's a very interesting case in https://forums.adafruit.com/viewtopic.php?f=60&t=165589 of some simple, killer code. From the description and analysis so far it sounds like an atypical, very lengthy operation in the interpreter seems likely to be the cause of USB problems due to starvation. Might be worth some brainstorming to work out if there are any other things that can cause this.

Reminds me of the ph34rsome nth-complexity infinite binary loop from years gone by http://fgouget.free.fr/goodtimes/goodtimes.html#sub13 :)

[dhalbert]

The original poster of https://forums.adafruit.com/viewtopic.php?f=60&t=165589, @derhexenmesiter,, has described the problem in #2949.