Skip to content

RFC Possible performance improvement for SPIRAM targets #8428

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
peterhinch opened this issue Mar 18, 2022 · 5 comments
Closed

RFC Possible performance improvement for SPIRAM targets #8428

peterhinch opened this issue Mar 18, 2022 · 5 comments
Labels
port-esp32

Comments

@peterhinch
Copy link
Contributor

The time for GC on an ESP32 without SPIRAM is ~1.8ms. Add SPIRAM and it goes to 100ms, impacting the latency of the soft-only interrupts. This cliff edge leads me to avoid SPIRAM modules where possible. It would be good if there were a way to avoid it.

One approach might be for the user to be able to specify (perhaps in boot.py) the maximum SPIRAM to be made available in the pool, from 0 upwards in increments of (say) 1MB.

Another approach would be to automate this. Initially the pool would comprise only internal RAM. If an allocation would cause OOM, 1MB of SPIRAM would be added to the pool. This would continue until SPIRAM was exhausted. In this way an application would only use the amount of SPIRAM it actually required. GC would take place in the current pool, so in small applications SPIRAM would never be used and GC would be fast. Adding to the pool would be a one way process - once a 1MB block was added, it would remain in place until reset.

This is an illustration - there may well be better algorithms than the above. For example adding a block before OOM actually occurs might improve performance by reducing fragmentation.
@robert-hh
Copy link
Contributor

Limiting the amount of SPIRAM for the heap might be the easier part, by starting with a small amount like 1M and being able to extend it once. Reducing it seems more complicated, if the heap is already populated.
In any case, SPIRAM is subject to cache misses and therefore slow.

@peterhinch
Copy link
Contributor Author

My thinking is based on the fact that boards like the UM Feather S2 have useful features, but include 8MB SPIRAM. For smaller, high performance applications, even the ability to disable SPIRAM in boot.py would be a big advantage. We win twice: with fast RAM and short GC time.

Reducing it seems more complicated, if the heap is already populated.

I don't envisage a need for this. The firmware would initialise with the heap restricted to internal RAM. The boot.py option (or algorithm) would only ever increase the size.

@peterhinch peterhinch mentioned this issue Mar 24, 2022
Closed
@peterhinch
Copy link
Contributor Author

Here is a practical issue reported by a user. In a uasyncio application GC was causing 300ms of additional latency between pressing a button and getting a response.

@peterhinch peterhinch mentioned this issue Apr 22, 2022
Closed
@dpgeorge
Copy link
Member

Another approach would be to automate this. Initially the pool would comprise only internal RAM. If an allocation would cause OOM, 1MB of SPIRAM would be added to the pool. This would continue until SPIRAM was exhausted.

I think this is a very good idea.

@tannewt
Copy link

tannewt commented Sep 28, 2023

This was done in #12141 and can be closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
port-esp32
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@tannewt @dpgeorge @peterhinch @robert-hh