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

vstr.c

Blame
    • Dave Hylands's avatar
      9f76dcd6
      py: Prevent many extra vstr allocations. · 9f76dcd6
      Dave Hylands authored
      I checked the entire codebase, and every place that vstr_init_len
      was called, there was a call to mp_obj_new_str_from_vstr after it.
      
      mp_obj_new_str_from_vstr always tries to reallocate a new buffer
      1 byte larger than the original to store the terminating null
      character.
      
      In many cases, if we allocated the initial buffer to be 1 byte
      longer, we can prevent this extra allocation, and just reuse
      the originally allocated buffer.
      
      Asking to read 256 bytes and only getting 100 will still cause
      the extra allocation, but if you ask to read 256 and get 256
      then the extra allocation will be optimized away.
      
      Yes - the reallocation is optimized in the heap to try and reuse
      the buffer if it can, but it takes quite a few cycles to figure
      this out.
      
      Note by Damien: vstr_init_len should now be considered as a
      string-init convenience function and used only when creating
      null-terminated objects.
      9f76dcd6
      History
      py: Prevent many extra vstr allocations.
      Dave Hylands authored
      I checked the entire codebase, and every place that vstr_init_len
      was called, there was a call to mp_obj_new_str_from_vstr after it.
      
      mp_obj_new_str_from_vstr always tries to reallocate a new buffer
      1 byte larger than the original to store the terminating null
      character.
      
      In many cases, if we allocated the initial buffer to be 1 byte
      longer, we can prevent this extra allocation, and just reuse
      the originally allocated buffer.
      
      Asking to read 256 bytes and only getting 100 will still cause
      the extra allocation, but if you ask to read 256 and get 256
      then the extra allocation will be optimized away.
      
      Yes - the reallocation is optimized in the heap to try and reuse
      the buffer if it can, but it takes quite a few cycles to figure
      this out.
      
      Note by Damien: vstr_init_len should now be considered as a
      string-init convenience function and used only when creating
      null-terminated objects.