NotificationsYou must be signed in to change notification settings
Fork13.3k
Star16.5k

[WString] Reduce build size by implementing flash string calls in .cpp#8106

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Jump to bottom

Merged

earlephilhower merged 2 commits intoesp8266:masterfromTD-er:String_build_size_reduction

Sep 4, 2021

Merged

[WString] Reduce build size by implementing flash string calls in .cpp#8106

earlephilhower merged 2 commits intoesp8266:masterfromTD-er:String_build_size_reduction

Sep 4, 2021

Conversation

Copy link

Contributor

TD-er commentedJun 7, 2021

A function called with a flash string, which only has an implementation withconst String& as argument will be compiled as if it is called with aString constructor wrapped around it.

For example this implementation in the .h file:

boolstartsWith(const __FlashStringHelper *prefix)const {returnthis->startsWith(String(prefix));}

This is completely useless as the compiler will generate exactly the same code with or without this function implementation in the .h file.
However if we move the implementation to the .cpp file, this conversion toString is only added once in the compiled binary.
In my own project I already managed to shrink the largest (ESP32) build by more than 70k in size (!!) by just adding extra function calls with the conversion in the .cpp file.
This PR is just a simple optimisation which already shrinks a very small build of my project by almost 3k in build size. (custom_beta_ESP8266_4M1M PIO env of ESPEasy)

Flash: [========  ]  82.5% (used 862137 bytes from 1044464 bytes)Flash: [========  ]  82.3% (used 859545 bytes from 1044464 bytes)

Larger builds may benefit even more.

[WString] Reduce build size by implementing flash string calls in .cpp

fe04afb

A function called with a flash string, which only has an implementation with `const String&` as argument will be compiled as if it is called with a `String` constructor wrapped around it.For example this implementation in the .h file:```c++bool startsWith(const __FlashStringHelper *prefix) const {            return this->startsWith(String(prefix));}```This is completely useless as the compiler will generate exactly the same code with or without this function implementation in the .h file.However if we move the implementation to the .cpp file, this conversion to `String` is only added once in the compiled binary.In my own project I already managed to shrink the largest (ESP32) build by more than 70k in size (!!) by just adding extra function calls with the conversion in the .cpp file.This PR is just a simple optimisation which already shrinks a very small build of my project by almost 3k in build size.  (custom_beta_ESP8266_4M1M PIO env of ESPEasy)```Flash: [========  ]  82.5% (used 862137 bytes from 1044464 bytes)Flash: [========  ]  82.3% (used 859545 bytes from 1044464 bytes)```Larger builds may benefit even more.

Copy link

Collaborator

mcspr commentedJun 8, 2021

I think it's also worth to mentionstrncmp_P, which could be used for const char* & FlashStringHelper, instead of String(...) conversion? Leaving basicstrncmp for the String.
(and since we already assume that const char*could be PSTR(...) with other const char methods)

Copy link

ContributorAuthor

TD-er commentedJun 8, 2021

Yep for those that can acceptconst char* that would be an option for sure as you don't need to copy the data from flash if not needed.
Would not make the build smaller, but the memory consumption would benefit from it.

Especially the webserver part would benefit from a similar approach as I have seen that sending flash strings directly to the webserver would make it incredible fast, but also highly unstable when running low on free memory. So if it doesn't need to copy flash strings to memory first but serve it directly from flash string (without the need to copy internally).
And I guess there are other areas too where it could be very useful to have such optimizations.

Copy link

Collaborator

earlephilhower commentedJun 10, 2021

Very nice idea! I think your app might be the single largest user ofStrings in the world, so most others won't see quite so dramatic a change, but this still seems like a great addition once the 3.0.x bugfixes are in and released.