Flashing significantly slower in `espflash v4` compared to `v3.3.0`

[AnthonyGrondin]

Bug description

I observed a noticeable flashing speed regression between espflash@v3.3.0 and espflash@v4.0.0. Flashing the same application with v4 takes significantly longer than with v3.

To verify this, I measured flashing times using the exact same application with both versions. Before each measurement, I erased the target partition to ensure a consistent starting state:

espflash erase-parts --partition-table ./partitions.csv factory

I also did an initial flash with each version, to set the bootloader for each version before taking a measurement.

Note

I also tested v4.3.0, which showed the same flashing performance as v4.0.0.
To reduce noise and clearly highlight the regression, the results below only compare v3.3.0 and v4.0.0, isolating the change to the transition from v3 → v4.

espflash v3.3.0:

Running `espflash flash --port /dev/ttyUSB1 --baud 921600 --monitor target/xtensa-esp32s3-none-elf/release/my_app`
[2026-03-10T20:00:40Z INFO ] 🚀 A new version of espflash is available: v4.3.0
[2026-03-10T20:00:40Z INFO ] Serial port: '/dev/ttyUSB1'
[2026-03-10T20:00:40Z INFO ] Connecting...
[2026-03-10T20:00:41Z INFO ] Using flash stub
[2026-03-10T20:00:43Z WARN ] Setting baud rate higher than 115,200 can cause issues
Chip type:         esp32s3 (revision v0.1)
Crystal frequency: 40 MHz
Flash size:        8MB
Features:          WiFi, BLE
MAC address:       7c:df:a1:e2:68:24
Partition table:   partitions.csv
App/part. size:    1,537,520/1,638,400 bytes, 93.84%
[2026-03-10T20:00:43Z INFO ] Segment at address '0x0' has not changed, skipping write
[2026-03-10T20:00:43Z INFO ] Segment at address '0x8000' has not changed, skipping write
[00:00:23] [========================================]     921/921     0x10000                                                                             
[2026-03-10T20:01:10Z INFO ] Flashing has completed!

espflash v4.0.0:

Running `espflash flash --port /dev/ttyUSB1 --baud 921600 --monitor target/xtensa-esp32s3-none-elf/release/my_app`
[2026-03-10T19:56:43Z INFO ] 🚀 A new version of espflash is available: v4.3.0
[2026-03-10T19:56:43Z INFO ] Serial port: '/dev/ttyUSB1'
[2026-03-10T19:56:43Z INFO ] Connecting...
[2026-03-10T19:56:44Z INFO ] Using flash stub
[2026-03-10T19:56:44Z WARN ] Setting baud rate higher than 115,200 can cause issues
Chip type:         esp32s3 (revision v0.1)
Crystal frequency: 40 MHz
Flash size:        8MB
Features:          WiFi, BLE, Embedded Flash
MAC address:       7c:df:a1:e2:68:24
App/part. size:    1,537,520/8,323,072 bytes, 18.47%
[00:00:00] [========================================]      14/14      0x0      Skipped! (checksum matches)                                                
[00:00:00] [========================================]       1/1       0x8000   Skipped! (checksum matches)                                                
[00:00:35] [========================================]     925/925     0x10000  Verifying... OK!                                                           
[2026-03-10T19:57:20Z INFO ] Flashing has completed!

• I have searched the existing issues (closed & open) to make sure the issue hasn't already been reported
• Check this box if you would like to work on a fix

To Reproduce

Steps to reproduce the behavior:

1. Install espflash@v3.3.0 (cargo binstall espflash@v3.3.0)
2. Clear factory partition (espflash erase-parts --partition-table ./partitions.csv factory)
3. Flash binary and measure time taken
4. Reproduce 1-3 with espflash@v4.0.0

• I have reproduced the bug in main branch too
  • v4.3.0 only

Expected behavior

Flashing should be at least as fast as previous versions (v3.3.0) or provide flags to disable extra functionalities that increase development feedback loop time.

Environment

• OS: Debian GNU/Linux 13 (trixie)
• espflash/cargo-espflash version: 4.0.0
• Target: ESP32-S3

[SergioGasquez]

It seems like the main reason for this is the stub change, in 3.3 we were using Rust stubs, while now we use C stubs, here is a quick test I did with current main:

The left terminal is using Rust stub, right terminal is using the current stub.

[AnthonyGrondin]

Could it be that the C stubs aren't running at max CPU speed?

https://github.com/espressif/esp-flasher-stub/blob/604dcd40c5884944925f70a6c442ac1e3cfa1e36/src/main.c#L39-L44

[SergioGasquez]

Closed in favour of espressif/esp-stub-lib#90