asyncHTTPrequest icon indicating copy to clipboard operation
asyncHTTPrequest copied to clipboard

use PROGMEM wherever possible

Open cpainchaud opened this issue 1 year ago • 5 comments

cpainchaud avatar Mar 10 '23 14:03 cpainchaud

Couple of issues:

PSTR is great for single instance literals, but take a look at the repetitiveness of some of the literals like "Content-Length" that are used many times. The PSTR macro will create multiple instances of that in progmem. Better to create one instance in Progmem and reference that.

I question the appropriateness of the two changes in xbuf. They don't appear to be acting on progmem data.

boblemaire avatar Mar 10 '23 15:03 boblemaire

Hi,

I read in a few places that PSTR was deduped and I think I remembered in the past testing this against simple examples for confirmation. That said I am wondering if anything changed recently in latest framework because this is what I get for ESP32 + [email protected]:

(no print added)
RAM:   [==        ]  20.4% (used 66712 bytes from 327680 bytes)
Flash: [=======   ]  66.0% (used 1254545 bytes from 1900544 bytes)

printf("SUPERLOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOONGSTRING");
RAM:   [==        ]  20.4% (used 66712 bytes from 327680 bytes)
Flash: [=======   ]  66.0% (used 1254641 bytes from 1900544 bytes)
+ 0 mem
+ 99 flash

printf("SUPERLOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOONGSTRING");
printf("SUPERLOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOONGSTRING");
RAM:   [==        ]  20.4% (used 66712 bytes from 327680 bytes)
Flash: [=======   ]  66.0% (used 1254657 bytes from 1900544 bytes)
+ 0 mem
+ 16 flash


printf_P(PSTR("SUPERLOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOONGSTRING"));
RAM:   [==        ]  20.4% (used 66712 bytes from 327680 bytes)
Flash: [=======   ]  66.0% (used 1254641 bytes from 1900544 bytes)
+ 0 mem
+ 99 flash

printf_P(PSTR("SUPERLOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOONGSTRING"));
printf_P(PSTR("SUPERLOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOONGSTRING"));
RAM:   [==        ]  20.4% (used 66712 bytes from 327680 bytes)
Flash: [=======   ]  66.0% (used 1254657 bytes from 1900544 bytes)
+ 0 mem
+ 16 flash


mixing
printf("SUPERLOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOONGSTRING");
printf_P(PSTR("SUPERLOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOONGSTRING"));
RAM:   [==        ]  20.4% (used 66712 bytes from 327680 bytes)
Flash: [=======   ]  66.0% (used 1254657 bytes from 1900544 bytes)
+ 0 mem
+ 16 flash```

cpainchaud avatar Mar 10 '23 15:03 cpainchaud

after investigation it seems that ESP32 doesn't require this : compiler will use progmem by default. It only affect ESP8266 for which I confirm that RAM is saved and PROGMEM strings are deduped

cpainchaud avatar Mar 10 '23 16:03 cpainchaud

Relative to ESP32 that was my conclusion from what you posted. TBH I don't use this with ESP32 and don't recommend it. I have an ESP32 version that provides the same interface but is not inherently asynchronous. If you need to avoid blocking, you can easily run it in a Freertos task on ESP32.

My ESP32 version also supports HTTPS.

I was not aware of any deduping in the ESP8266. That would probably be a change in the toolchain but I am not able to use the latest toolchain in my commercial product for compatibility reasons. So if you still need this change, I'd like to see the progmem deduped as recommended. Also, the xbuf issue has not been addressed.

boblemaire avatar Mar 10 '23 16:03 boblemaire

I really needed the asynchronous side and it would have forced me to create 2 different codes for my project which supports both hardwares.

concerning xbuf changes I suppose you are questioning the if/why use strcpy vs strcpy_P , I was having issues (unexplained bugs) until I switched to the _P

cpainchaud avatar Mar 10 '23 16:03 cpainchaud