Keep in mind, the steps Kolban mentioned above might be done in CPU microcode. Same effect - some types of access are slower than others.

The word you are looking for is ‘twisted’.

Modern Ethernet cables use twisted pairs, with differential signaling, to achieve high rates.

Ordinary I2C doesn’t use differential signaling. For long runs, differential transceivers are available for I2C.

Depending on how you’ve wired the button and encoder, you may need pull-ups or pull-downs, either internal or external.

If you’re on a linux or other Unix-like system, you can write a shell script to wrap bin/esp32ulp-elf-nm and handle the redirection into a file.

That sounds correct.

Another possibility- develop and debug your ULP code using IDF, then convert the result into hex text, and embed it in your Arduino code.

Is this a question?

Interesting.
I ran that code on 8266 and esp32, and times were about the same on both. About 10000 to 11000ms.

Reading one byte at a time is a bad idea on 8266, too. client.available() returns the number of bytes ready to be read.

Also, on 8266, WiFi connection seems fast, because by default, it automatically connects to the last AP used, before you call WiFi.begin(). I don’t know if ESP32 does that.

Probably unrelated, but seems to me all access to the SD card should be between SD.begin() and SD.end().

fgets() returns char*, not int.