Summary

My MicroPython port has relatively large flash storage, but not much RAM (only 100 KB is available for MicroPython heap). Therefore I rely on frozen modules to save RAM. My port includes SYS_SETTRACE to allow the end user to debug their own code using Visual Studio Code.

Examining my runtime heap map in detail, I realised that frozen functions use a significant amount of RAM: 32 bytes per function or method. This equated to 20 KB of RAM when importing my main library.

Further investigation revealed a significant waste of ROM and RAM when enabling SYS_SETTRACE. This pull request attempts to address this issue:

• the first commit reduces the footprint of themp_raw_code_t structure, which uses unnecessary ROM space in frozen code, but also uses RAM for dynamically loaded functions. Depending on the port options, this may also reduce the code footprint for builds not using SYS_SETTRACE.
• the second commit solves the problem ofmp_obj_fun_bc_t objects using two GC units instead of one when SYS_SETTRACE is enabled. This requires the use of a different structure for each kind of function object, instead of just two types as it is currently the case, so some assumptions about the usage of function objects had to be made more explicit.
• the third commit goes one step further by adding support for frozenmp_obj_fun_bc_t objects, not using any RAM. This improvement may benefit to any port with frozen modules, even when SYS_SETTRACE is not enabled. The price to pay for this is of course a bit of ROM, and the use of an indirect pointer to load the module globals dictionary.

edit on 2025-10-31: this third commit has been updated based on the alternative implementation that I had considered in my first submit, i.e. frozing themp_module_context_t object as well, with just the pointer to the module-specific globals dictionary in RAM. This results in simpler code so I think this is preferable. The first version is still available on my repository for reference if needed.

Testing

The code has been extensively tested on my port, executing both frozen and runtime code.

I started from a build with 185 KB of rodata for frozen modules. Loading my main frozen library used 36KB RAM (for defining classes involving about 600 methods). After the optimizations, I ended up with 162 KB of rodata for frozen modules, and only 17KB RAM used after loading my main library.

So the total savings in my case are 20 KB flash, 20 KB RAM.

I have enabled the new features for some configurations of CI tests to be sure they are covered.

Trade-offs and Alternatives

There are other ways to somehow reduce the RAM footprint of frozen modules, such as lazy loading (as done in asyncio for instance). I have gone that way first, but ultimately:

• there was still way to much RAM wasted once I had loaded the libraries that I needed
• the lazy loading solution tends to defeat type checking algorithms used by IDE
• the lazy loading solution breaks if the user uses a star import
• cross references between multiple classes is really tricky to implement properly with the lazy loading method
  So ultimately, freezingmp_obj_fun_bc_t objects was a much cleaner solution.