Need Clarification for ESP-IDF (ESP32S2) memory footprint (IDFGH-5238)

[Darsh-Dev]

Hi Team,

I want to understand the memory footprint of ESP-IDF. Hello-world example is taking by default 162816 bytes memory.
Why its consumed >150KB for simple hello world code?

esp-idf/examples/get-started/hello_world/build/hello-world
hello-world.map.txt

Total sizes:
DRAM .data size: 10648 bytes
DRAM .bss size: 2088 bytes
Used static DRAM: 12736 bytes ( 168000 available, 7.0% used)
Used static IRAM: 43609 bytes ( 87463 available, 33.3% used)
Flash code: 80147 bytes
Flash rodata: 28412 bytes
Total image size:~ 162816 bytes (.bin may be padded larger)

Also, I am trying with AWS IoT example code (additionally CLI, NVS, UART, WiFi, ESP-IDF SDK/libs).
Same basic example also consuming the 900KB memory

Total sizes:
DRAM .data size: 17036 bytes
DRAM .bss size: 30376 bytes
Used static DRAM: 0 bytes ( 0 available, nan% used)
Used static IRAM: 0 bytes ( 0 available, nan% used)
Used stat D/IRAM: 134071 bytes ( 242761 available, 35.6% used)
Flash code: 640511 bytes
Flash rodata: 151896 bytes
Total image size:~ 896102 bytes (.bin may be padded larger)

We have also checked the .map file, but I can't understand the below names

1. .debug_* (After disable the debug logs not found measure difference in the code size)
2. .xt.* (lit, prop...)
3. .literal.

Will be appreciated your help. Thanks

[negativekelvin]

https://stackoverflow.com/questions/58532567/can-we-reduce-esp-idf-boiler-plate-size

[projectgus]

Hi @Darsh-Dev,

Thanks for being patient while someone got back to you. To make sure we're discussing the same issue, in this case your concern is the application binary size in the flash rather than the RAM usage. Is that right?

We're in the process of preparing a performance guide which includes sections on minimizing the binary size and also the RAM usage of an ESP-IDF app. Will link it to this issue once it's available.

Regarding hello_world, in general ESP-IDF applications only link the code and data which is referenced by the application. However there is some system-level functionality that is included in every app by default even though it's not really used by very simple apps like hello world. (Features such as: high precision timer, task watchdogs, interrupt watchdogs, panic handler code). It is possible to trim some of these down but most non-trivial apps will either need or want them.

Regarding the AWS IoT example, this app contains quite a lot of additional functionality (including the Wi-Fi stack, TCP/IP stack, a compliant TLS stack, and the relevant AWS SDK functionality).

The default ESP-IDF configuration is also targeted for maximum functionality and easy debug-ability, rather than code size. One of the simplest size improvements is to change the compiler optimization level to Size. There are a number of other possible actions listed in the upcoming Performance Guide, will link to this as soon as it's available.

The idf.py size and related tools in the linked Stack Overflow post are very useful as well, the output from these commands can be much easier to understand than reading the map file manually.

.debug_* (After disable the debug logs not found measure difference in the code size)
.xt.* (lit, prop...)

These are metadata sections that are in the ELF file but not the binary file, so they don't affect the final binary size.

.literal.

Literals are generated by the compiler to store values which can't be efficiently encoded in instructions. They contribute to the application binary size, generally the literal size is proportional to the size of the .text sections.