Skip to content
Snippets Groups Projects
Select Git revision
  • bbab73f6a0ede36dabd79b117e332275d855a5b5
  • main default protected
  • blm_dev_chan
  • release/1.4.0 protected
  • widgets_draw
  • return_of_melodic_demo
  • task_cleanup
  • mixer2
  • dx/fb-save-restore
  • dx/dldldld
  • fpletz/flake
  • dx/jacksense-headset-mic-only
  • release/1.3.0 protected
  • fil3s-limit-filesize
  • allow-reloading-sunmenu
  • wifi-json-error-handling
  • app_text_viewer
  • shoegaze-fps
  • media_has_video_has_audio
  • fil3s-media
  • more-accurate-battery
  • v1.4.0
  • v1.3.0
  • v1.2.0
  • v1.2.0+rc1
  • v1.1.1
  • v1.1.0
  • v1.1.0+rc1
  • v1.0.0
  • v1.0.0+rc6
  • v1.0.0+rc5
  • v1.0.0+rc4
  • v1.0.0+rc3
  • v1.0.0+rc2
  • v1.0.0+rc1
35 results

mpstate.h

  • Damien Tournoud's avatar
    bbab73f6
    py/gc: Speed up incremental GC cycles by tracking the last used block. · bbab73f6
    Damien Tournoud authored and moon2's avatar moon2 committed
    
    In applications that use little memory and run GC regularly, the cost of
    the sweep phase quickly becomes prohibitives as the amount of RAM
    increases.
    
    On an ESP32-S3 with 2 MB of external SPIRAM, for example, a trivial GC
    cycle takes a minimum of 40ms, virtually all of it in the sweep phase.
    
    Similarly, on the UNIX port with 1 GB of heap, a trivial GC takes 47 ms,
    again virtually all of it in the sweep phase.
    
    This commit speeds up the sweep phase in the case most of the heap is empty
    by keeping track of the ID of the highest block we allocated in an area
    since the last GC.
    
    The performance benchmark run on PYBV10 shows between +0 and +2%
    improvement across the existing performance tests.  These tests don't
    really stress the GC, so they were also run with gc.threshold(30000) and
    gc.threshold(10000).  For the 30000 case, performance improved by up to
    +10% with this commit.  For the 10000 case, performance improved by at
    least +10% on 6 tests, and up to +25%.
    
    Signed-off-by: default avatarDamien George <damien@micropython.org>
    bbab73f6
    History
    py/gc: Speed up incremental GC cycles by tracking the last used block.
    Damien Tournoud authored and moon2's avatar moon2 committed
    
    In applications that use little memory and run GC regularly, the cost of
    the sweep phase quickly becomes prohibitives as the amount of RAM
    increases.
    
    On an ESP32-S3 with 2 MB of external SPIRAM, for example, a trivial GC
    cycle takes a minimum of 40ms, virtually all of it in the sweep phase.
    
    Similarly, on the UNIX port with 1 GB of heap, a trivial GC takes 47 ms,
    again virtually all of it in the sweep phase.
    
    This commit speeds up the sweep phase in the case most of the heap is empty
    by keeping track of the ID of the highest block we allocated in an area
    since the last GC.
    
    The performance benchmark run on PYBV10 shows between +0 and +2%
    improvement across the existing performance tests.  These tests don't
    really stress the GC, so they were also run with gc.threshold(30000) and
    gc.threshold(10000).  For the 30000 case, performance improved by up to
    +10% with this commit.  For the 10000 case, performance improved by at
    least +10% on 6 tests, and up to +25%.
    
    Signed-off-by: default avatarDamien George <damien@micropython.org>