ESP32-S3 Blink is 54 KB larger when built with fbuild than with the previous backend

[zackees]

Summary

The same FastLED source builds a 54 KB larger ESP32-S3 Blink with fbuild than it did with the PlatformIO backend FastLED used before switching to fbuild-only builds. FastLED's bloat gate had to be re-baselined for it (FastLED/FastLED#4418).

Backend	Blink total flash, esp32s3	CI runs
PlatformIO (before FastLED/FastLED#4412)	336,465 B	every run through 2026-09-13 09:58Z
fbuild 2.5.23	390,453 B	4 of 4 runs since, identical each time
Difference	+53,988 B (+16%)

The number is deterministic on CI, so this is a real difference between the two builds, not noise.

How it is measured

FastLED's tests/test_esp32s3_bloat_regression.py runs bash bloat esp32s3 --build, which compiles examples/Blink for the esp32s3 board and then runs fbuild symbols on the resulting ELF. total_flash comes from that report.

Before FastLED/FastLED#4412, bash bloat --build forced the PlatformIO backend. After it, the same command builds with fbuild. Nothing else changed in the measurement.

fbuild build details from the CI log:

• fbuild 2.5.23
• xtensa-esp-elf-gcc 14.2.0
• framework-arduinoespressif32 3.3.11
• Board: Espressif ESP32-S3-DevKitC-1-N8, -Os

The PlatformIO toolchain and framework versions for the older runs are not in the logs I read, so a version difference on that side is not ruled out.

Where to look

Largest flash symbols in the fbuild build, from the failing gate's output:

Bytes	Archive	Symbol
11,222	libc.a	_svfprintf_r
4,032	libFastLED.a	fl::Channel::showPixels(...)
3,223	libc.a	_dtoa_r
2,031	libesp_driver_rmt.a	rmt_new_tx_channel
1,872	(none)	uartSetPins
1,745	libesp_hw_support.a	rtc_init
1,619	libespcoredump.a	esp_core_dump_do_write_elf_pass
1,596	libespressif__esp_diag	diag_log_add

Candidates worth comparing against the PlatformIO build of the same sketch, none verified:

• libc printf. Full _svfprintf_r and _dtoa_r suggest the non-nano newlib printf with float support is linked.
• Core dump and diagnostics. esp_core_dump_* and esp_diag are present, which may be SDK-config differences between the frameworks.
• Link flags and garbage collection. LTO state, --gc-sections coverage, and which precompiled SDK archives are pulled in.
• Framework version. arduino-esp32 3.3.11 versus whatever the PlatformIO platform pinned.

A symbol-level diff of the two ELFs would settle it quickly. The PlatformIO build is no longer reproducible from current FastLED master, so it would need a checkout from before FastLED/FastLED#4412.

Evidence

• fbuild runs, 390,453 B: 34756836812, 34757628256, 34759929366, 34876869926
• PlatformIO runs, 336,465 B: 34750631321, 34749620465
• Re-baseline with the reason recorded: ci: compile a smoke example set on pull requests, all examples on master FastLED#4418
• Related build-time analysis: ESP32-S3 example gate takes 33 minutes: where the time goes FastLED#4415

A local build on the same fbuild version measured 394,561 B, 4 KB more than CI. That gap is probably leftover state in the local build directory and is not verified.

🤖 Generated with Claude Code

https://claude.ai/code/session_01M9rUkvoW2gVKYurtQJpi4i