boblemaire / asyncHTTPrequest

asynchronous HTTP for ESP using ESPasyncTCP. Works like XMLHTTPrequest in JS.
GNU General Public License v3.0
64 stars 31 forks source link

use PROGMEM wherever possible #46

Open cpainchaud opened 1 year ago

boblemaire commented 1 year ago

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.

cpainchaud commented 1 year ago

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 + espressif32@6.1.0:


 (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 commented 1 year ago

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

boblemaire commented 1 year ago

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.

cpainchaud commented 1 year ago

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