Trimming building unnecessary IDF modules

[eriksl]

Understandably and I already turned off a lot of these...

Sometimes I feel like analysing the linker map to find out. That's not so simple, so I don't want to spend much time on it if besides me nobody really cares. And of course I'd rather have Espressif do it themselves.

[boarchuz]

Setting compiler optimisation to 'Size', log level to 'None', and assertions to 'Silent' should get you most of the way there. Enabling nano formatting options also helps a lot iirc (uses printf in ROM so you don't need it linked in your binary).

Also see: https://docs.espressif.com/projects/esp ... /size.html

[eriksl]

Yes I know these. But they're not going to make the real difference. I cannot imagine there are so many assertions with so much text, that they may up 500 kB of space, do you?

And optimisation (-O3 -> Os) is already set of course. In my experience that makes 15-25% percent difference in code size. The positive effect of -O3 is often overestimated, especially on microcontrollers. The larger code makes a cache miss more probable. Cache miss is a lot more expensive than a few instructions more (when e.g. unrolling a loop), especially when dealing with SPI flash behind the cache.

[MicroController]

All of these which are handy an nice if they're facilitated by the compiler. But they're not enabling something you can't do in C (with correct programming, something many peolpe struggle with).

And C is not enabling anything you can't do in assembly. That's not the point.

Ok so let's rephrase my question.

Sorry, but you keep asking the same question again and again while rejecting answers provided to try and solve your problem.
If you insist that it's "C++" that's inflating your project and you still don't want to check where the culprit actually is, I guess you'll have to live with what you have now.

Maybe consider this: If your problem was intrisic in the ESP32s or the IDF, and not your specific envrionment or application, why don't many more people have the same complaint?

[eriksl]

I already wrote I actually don't even mind the C++ part. As long as they fix the bloating, one way or the another.

Sorry but many users are Arduino level. They're entirely happy when it runs their 10 line script (or whatever it's called there).

I am coming from a world (a.o. ATTiny and ATMega) where you could do A LOT with a few bytes. Yes, I really have a problem with wasteful behaviour. And as said, I do see a future problem with my image growing and growing just because it draws in lots of bloatware from the IDF libs and finally not fitting anymore in my, not so modest, 4 MB flash chips.

[MicroController]

It may be noteworthy that with your application code growing the differential increase in binary size per line of code added will approach 0. The 'first line' of an application's code may (seem to) require a few hundred KB of flash because all the one-off stuff needs to be linked in (WIFI driver, OS,...), but once most/all needed IDF components are already linked into the application, each new line of application code may only need a few bytes.

I broke down a small C++ project (HTTP server over WiFi on an ESP32-C3), roughly classified its components, and got flash usage like this:

WiFi: 260KB, of which ~150KB are libnet80211 plus ~70KB libwpa_supplicant
Network: ~207KB, in which I included ~110KB of libmbedcrypto because my application doesn't explicitly use crypto, but lwip does.
System stuff (low-level hardware support and memory manangement): ~110KB
Stdlibs (C, C++, gcc): ~75KB, of which libc is ~51KB
HTTP server component: ~35KB
FreeRTOS: 20KB
Application (C++): ~21KB, including HTTP file-serving from a minimal file system in a flash partition, server-sent events, and a OneWire driver.
Total flash usage: ~840KB

The required network stuff alone takes 400-500KB. Not much we can do about that. But it's a one-off cost.