As per the implementation of m_malloc0, if MICROPY_GC_CONSERVATIVE_CLEAR is set then all RAM is guaranteed to be zero-init by gc_alloc.

py/objarray.c: Guard the explicit zero init in bytearray_make_new against being run, initialising the RAM to zero a second time, if this flag is set.

py/objstr.c: Guard the explicit zero init in bytes_make_new against being run, initialising the RAM to zero a second time, if this flag is set.

Note that MICROPY_GC_CONSERVATIVE_CLEAR is default enabled by MICROPY_ENABLE_GC, and no ports currently override this value.

We stumbled across this inconsistency when testing the timings of allocating, collecting and collecting/freeing PSRAM, with a script looking something like the following:

import gc
import time

t_start = time.ticks_us()
gc.collect()
t_taken = time.ticks_diff(time.ticks_us(), t_start)
baseline = t_taken / 1000
print(f"Baseline: {t_taken / 1000:.2f}ms")


for y in range(1, 41):
    b4 = gc.mem_free()
    t_start = time.ticks_us()
    test = bytearray(1024 * y * 10)
    alloc_time_ms = time.ticks_diff(time.ticks_us(), t_start) / 1000
    af = gc.mem_free()

    t_start = time.ticks_us()
    gc.collect()
    t_taken = time.ticks_diff(time.ticks_us(), t_start)

    ram_used = (b4 - af) / 1024
    time_ms = t_taken / 1000
    factor = (time_ms - baseline) / ram_used

    del test
    
    t_start = time.ticks_us()
    gc.collect()
    collect_time_ms =  time.ticks_diff(time.ticks_us(), t_start) / 1000
    print(f"{int(ram_used):4d} {time_ms: 7.2f} {collect_time_ms: 7.2f} {alloc_time_ms: 7.2f} {factor: 6.2f}")

We had a custom image class which did its own allocation via m_malloc internally, and found - quite unintentionally - that it was twice as fast to allocate our custom image versus an identically sized bytearray. A little sleuthing revealed that bytearray ignores the value of MICROPY_GC_CONSERVATIVE_CLEAR and will zero (using memset()) RAM that is already guaranteed to be zeroed by gc_alloc, eg:

when gc_alloc already does:

Testing

To ensure no non-zero values leaked into bytearrays I ran this very basic test with various maximum sizes:

for s in range(1024):
    if sum(bytearray(s)) > 0:
        raise RuntimeError(f"{s}: FAIL! - Non zero init bytearray found.")

And here are the bytes(n) alloc times, on PSRAM with an RP2350 clocked to 200MHz both before and after the change`:

Trade-offs and Alternatives

I am unsure if there is some subtle caveat for gc_alloc zero init that might cause problems specifically with a bytearray, but afaict this change is minimal and gives us bytearray allocations in roughly half the time.

This is less noticeable on SRAM (tested on RP2350) where a 200k allocation takes 2.6ms, but on PSRAM it brings a 200k bytearray alloc from roughly 50ms down to 25ms, and a modest 10k alloc from 2ms down to 1ms. The alloc time for sizes between these two extremes is linear.