Misconception about module freezing

[ProjectRobal]

Hello, I have read about module freezing and done manifest file according to that page:
https://docs.micropython.org/en/latest/reference/manifest.html#manifest

As I understand it is supposed to freeze some modules into firmware of ESP-32 by doing so, scripts would execute from flash memory rather than from RAM.
I have edited for generic esp board manifest file:

freeze("$(PORT_DIR)/modules")
include("$(MPY_DIR)/extmod/uasyncio")
include("$(PORT_DIR)/frezze/ads1x15")
include("$(PORT_DIR)/frezze/tinyweb")
include("$(PORT_DIR)/frezze/logging")
include("$(PORT_DIR)/frezze/screens")
include("$(PORT_DIR)/frezze/uwidget")

require("dht")
require("ds18x20")
require("mip")
require("neopixel")
require("ntptime")
require("onewire")
require("umqtt.robust")
require("umqtt.simple")
require("upysh")
require("urequests")
require("webrepl")

But when I try to import for example dht or other frozen module, those are still takes some space in RAM.
Is it normal? Or I am missing something. I can provide more information if needed.

[mattytrentini]

As I understand, some RAM will still be used. For each frozen class there's a small 'stub' class instantiated in RAM that forwards across to the code residing on flash. However, significantly less memory should be used, compared with running the entire code from flash.

[ProjectRobal]

It may be true, I have tried to import modules normal way on unmodified micropython image, the RAM usage is higher than with importing frozen modules.

[jimmo]

For each frozen class there's a small 'stub' class instantiated in RAM that forwards across to the code residing on flash.

That's not quite accurate about the stub/forwarding, but the general point is true -- some RAM will still be used for some structures, but the bulk of the RAM used.

There are four things that matter here:

• Constant objects (e.g. tuples, byte-strings, strings) (stay in ROM)
• Bytecode (stays in ROM)
• Code state (e.g. the function object that wraps that bytecode, must be created in RAM)
• Program state (e.g. anything that your program creates. e.g. if your module has a method, then the globals dict (RAM) contains an entry for that method).

Note that in particular that fourth one is entirely dependent on what your code does. If your code allocates a giant list, then freezing isn't going to do anything to help reduce that.

[robert-hh]

I assume that you have rebuilt the firmware after changing the manifest files. As a Matt said, freezing causes the code for be executed from flash, The data that is allocated by the code will still reside in RAM. And you will see that mem_free() decreases for every command executed from REPL. But that memory use is just temporary. To to compare the amount of memory being used by the import, you have to use something like gc.collect();gc.mem_free() before and after the import statement.