Skip to content

RFC Possible performance improvement for SPIRAM targets #8428

@peterhinch

Description

@peterhinch

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.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      pFad - Phonifier reborn

      Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

      Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


      Alternative Proxies:

      Alternative Proxy

      pFad Proxy

      pFad v3 Proxy

      pFad v4 Proxy