Replies: 10 comments
-
|
Thats git. In previous versions the framework was completely stored in git with all binaries. So the repo is big with this history. |
Beta Was this translation helpful? Give feedback.
-
|
This is the platformio.ini Thought it was platform-espressif32.zip, but when I optimized that I got negligible speed increase. Is the git repository coming from the framework link? |
Beta Was this translation helpful? Give feedback.
-
|
None of my pioarduino releases downloads anything via git (clone). All needed packages are stripped down and uses either zip or xz tar balls. The biggest zip is the arduino lib with the precompiled binaries ~350Mbyte. |
Beta Was this translation helpful? Give feedback.
-
|
I use pioardiuno for everything. I'm telling you man, it's 10GB. I have no idea why yet. I may dive into the container today to find out where all the bloat is coming from. This explains why it's taking 15-25 minutes to install esp32XX |
Beta Was this translation helpful? Give feedback.
-
|
I did some auditing of the container and wanted to share the results. I don't see a github repo being installed. I do see a multi platform deploy Container deep dive (host in this case is mapped in and doesn't count) And here's some AI analsyis: You’re looking at a multilib RISC-V toolchain from Espressif. The huge space is coming from the same runtime libraries being compiled for multiple ISA variants/ABIs, plus a couple of “flavors” (full vs nano, RTTI vs no-RTTI), and most of them are LTO-enabled archives (which are big). Here’s what those “mystery” chunks are: rv32i_zicsr_zifencei / rv32imc_zicsr_zifencei / rv32imac_zicsr_zifencei / rv32imafc_zicsr_zifencei / rv32imafc_zicsr_zifencei_zba_zbb_zbc_zbs (≈ 220–224 MB each) rv32i = base integer m = mul/div, a = atomics, f = single-precision float, c = compressed zicsr/zifencei = mandatory control/status & fence extensions zba/zbb/zbc/zbs = bit-manip extensions (used on newer cores like C6/P4) libstdc++.a (85 MB), libg.a (28.5 MB), libc.a (28.5 MB), libg_nano.a/libc_nano.a (≈23 MB each), libm*.a (≈7.6 MB), libsupc++.a (4.1 MB) libstdc++.a + libsupc++.a = C++ standard library and low-level C++ runtime. libc*.a, libm*.a = picolibc (or nano builds) and math. The “nano” variants are size-tuned builds (fewer features, smaller stdio, etc.). Size is large because these are static libraries with LTO sections (bitcode/IR) and lots of templates; the archives pack a ton of object files so the linker can pick what it needs. no-rtti/ (111 MB) ldscripts/, *.specs, crt0.o, crt1-sim.o libnosys.a (stubs), libgloss.a/libsemihost.a/libsim.a/libsys_qemu.a, libpthread_stubs.a picolibc/ (775 MB at the package root) Why so big overall? Multilib explosion: ~5 ISA/ABI variants × (libstdc++ + supc++ + libc + libm + libgcc + …). LTO archives: objects store intermediate representation, which bloats .a size even though the final ELF you build may still be small. Both full and “nano” flavors, and no-RTTI flavor too. Duplicate placement (per-variant dirs plus a default copy at the lib root; plus the separate picolibc/ tree). Quick ways to verify what’s inside (pick any .a or a file in a multilib dir): Show the multilib matrix this GCC supportsriscv32-esp-elf-gcc -print-multi-lib See which ISA/ABI a given object was built forriscv32-esp-elf-readelf -A rv32imafc_zicsr_zifencei/lib/libstdc++.a | head List members in a fat archiveriscv32-esp-elf-ar t libstdc++.a | head -n 50 Check if LTO/IR is present (look for .gnu.lto_ or LLVM bitcode)riscv32-esp-elf-nm -a libstdc++.a | head If you want to reclaim space (without breaking your builds): Keep only the multilib you actually use (e.g., for ESP32-C3: rv32imc_zicsr_zifencei; for ESP32-C6/P4: the rv32imafc...zba_zbb_zbc_zbs dir). You can move the others out of the way. Use “nano” and/or no-RTTI: point GCC to nano.specs or pick libs from no-rtti/ to reduce final binary size (and you can prune the unused full variants). Strip debug info from archives (careful, test this): riscv32-esp-elf-strip -g path/to/libsomething.a Deduplicate with hardlinks if multiple copies are byte-identical across dirs (sometimes they are). Tools like rdfind/fdupes can help. If you control the toolchain build: disable LTO in shipped archives or provide a “slim toolchain” with only one multilib. Bottom line: those 200-220 MB folders are per-ISA copies of the same standard libraries; the 85 MB libstdc++.a and ~23-28 MB libc variants are LTO-enabled static archives; no-rtti is an alternative C++ lib flavor; and the rest are syscall/semihost/sim support libraries and specs. |
Beta Was this translation helpful? Give feedback.
-
|
Recommended sample esp32p4 "thin" build That would take out the largest redudancy. I wondered if there was xtensa and riscv, but it seems that surprisingly there's only riscv installed. I'm not sure how platformio is able to just generate one platform for a url that supports multiple platforms. Is it by any chance compiling riscv on the fly? (update no it's not compiling) That would explain why it takes so long, if it's being built. I may dive more into this later. |
Beta Was this translation helpful? Give feedback.
-
|
No, only the toolchain which is needed is installed. Build for esp32 and the xtensa toolchain is downloaded and installed. |
Beta Was this translation helpful? Give feedback.
-
|
To minimize downloads, you could preload the Docker Image with all tools and toolchains matching for the OS. All this stuff is downloaded into folder |
Beta Was this translation helpful? Give feedback.
-
AI says this is the same toolset, but with slightly different flavors. Instead of 1.2GB it could be 250mb |
Beta Was this translation helpful? Give feedback.
-
|
Yes, and needed since the espressif riscv mcu have different hardware features and extensions. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Board
ESp32S3, IDF 5.5
Device Description
I was hoping to speed up the builds via docker. It worked actually really well to get around pathological platformio redownloading.
10GB, I know it says ~14GB but the uno build is 4GB Docker Image and that's tiny so 14 - 4 = 10 GB payload for IDF.
What makes it so big? Are you including precompiled libs for all the dev boards as a monobuild?
Feel free to close this issue or move it to discussion. But wow, 10GB.
Hardware Configuration
ESP32S3 on platformio
Version
latest stable Release (if not listed below)
Type
Task
IDE Name
platformio
Operating System
windows
Flash frequency
40
PSRAM enabled
yes
Upload speed
115200
Description
Big payload for a tiny board
Sketch
Debug Message
Other Steps to Reproduce
No response
I have checked existing issues, online documentation and the Troubleshooting Guide
Beta Was this translation helpful? Give feedback.
All reactions