It was pointed out to me that ecppack has a compress option and it has quite the impact on programming speeds, so I thought I'd do a simple test and try a few different compression combinations and see what impact they have (you never quite know with these things till you try)
| File name | Size (bytes) | Time 1 | Time 2 | Time 3 | Time 4 | Time 5 | Ave Time(ms) |
| blink.bit | 1032325 | 2059 | 1944 | 1928 | 2160 | 2393 | 2097 |
| blink.bit.gz | 6112 | 4967 | 5010 | 5074 | 4710 | 4764 | 4905 |
| blinkc.bit | 162070 | 394 | 343 | 315 | 306 | 332 | 338 |
| blinkc.bit.gz | 2856 | 1982 | 1824 | 1838 | 1870 | 1895 | 1882 |
blinkc.* has been compressed by ecppack --compress, all the tests were carried out from a laptop running lighttpd, the network connection is 5Ghz WIFI to the router from the laptop, with the esp32 connected via 2Ghz WIFI. The following command was used from the webrepl console to program the bitstream into SRAM (not flash).
ecp5.prog("http://192.168.0.40/blink.bit")
While ecppack's compress option isn't amazing (in this case just over 15% of the original size) it has a marked impact on programming speed taking only 16% of the time it takes to program a vanilla bit stream. Simply gzipping the file gives the worst speed, presumably its the esp32 that's decompressing gz files... Using both compression methods has the best effect on file size and the price paid in speed doesn't rule it out...
As I'm storing my bitstreams on my laptop and programming from there, I don't really care about file size, but its well worth using ecppack's compression as the speed of programming really stella ! (...and no thats not a load of typo's, 300ms not 3000ms !)
This is my main use case, but at a later date I may do the same tests on the esp32 internal flash vs from the onboard SD card....