Skip to content
Snippets Groups Projects
Select Git revision
  • dualcore
  • ch3/leds
  • wip-bootstrap default
  • ch3/time
  • master
5 results

mpy-tool.py

Blame
    • Rich Barlow's avatar
      6e5a40cf
      tools/mpy-tool: Set sane initial dynamic qstr pool size with frozen mods · 6e5a40cf
      Rich Barlow authored
      The first dynamic qstr pool is double the size of the 'alloc' field of
      the last const qstr pool. The built in const qstr pool
      (mp_qstr_const_pool) has a hardcoded alloc size of 10, meaning that the
      first dynamic pool is allocated space for 20 entries. The alloc size
      must be less than or equal to the actual number of qstrs in the pool
      (the 'len' field) to ensure that the first dynamically created qstr
      triggers the creation of a new pool.
      
      When modules are frozen a second const pool is created (generally
      mp_qstr_frozen_const_pool) and linked to the built in pool. However,
      this second const pool had its 'alloc' field set to the number of qstrs
      in the pool. When freezing a large quantity of modules this can result
      in thousands of qstrs being in the pool. This means that the first
      dynamically created qstr results in a massive allocation. This commit
      sets the alloc size of the frozen qstr pool to 10 or less (if the number
      of qstrs in the pool is less than 10). The result of this is that the
      allocation behaviour when a dynamic qstr is created is identical with an
      without frozen code.
      
      Note that there is the potential for a slight memory inefficiency if the
      frozen modules have less than 10 qstrs, as the first few dynamic
      allocations will have quite a large overhead, but the geometric growth
      soon deals with this.
      6e5a40cf
      History
      tools/mpy-tool: Set sane initial dynamic qstr pool size with frozen mods
      Rich Barlow authored
      The first dynamic qstr pool is double the size of the 'alloc' field of
      the last const qstr pool. The built in const qstr pool
      (mp_qstr_const_pool) has a hardcoded alloc size of 10, meaning that the
      first dynamic pool is allocated space for 20 entries. The alloc size
      must be less than or equal to the actual number of qstrs in the pool
      (the 'len' field) to ensure that the first dynamically created qstr
      triggers the creation of a new pool.
      
      When modules are frozen a second const pool is created (generally
      mp_qstr_frozen_const_pool) and linked to the built in pool. However,
      this second const pool had its 'alloc' field set to the number of qstrs
      in the pool. When freezing a large quantity of modules this can result
      in thousands of qstrs being in the pool. This means that the first
      dynamically created qstr results in a massive allocation. This commit
      sets the alloc size of the frozen qstr pool to 10 or less (if the number
      of qstrs in the pool is less than 10). The result of this is that the
      allocation behaviour when a dynamic qstr is created is identical with an
      without frozen code.
      
      Note that there is the potential for a slight memory inefficiency if the
      frozen modules have less than 10 qstrs, as the first few dynamic
      allocations will have quite a large overhead, but the geometric growth
      soon deals with this.