WString: Optimize a bit more by jjsuwa-sys3175 · Pull Request #7758 · esp8266/Arduino (original) (raw)

I have spent quite a lot of time on my own project to prevent lots of casts to String from a flash string, by adding function wrappers to frequently used functions accepting a flash string as an argument.
This reduced the compiled binary size A LOT(!!!). For the largest binary I could gain over 70k in size.

But there is still a lot to gain as a lot of compares like operator == of the String class do not have a variant accepting a flash string as an argument.
So can you add those too (implement in the .cpp !!!) like:

unsigned char operator ==(const __FlashStringHelper *fstr) const;

unsigned char String::operator ==(const __FlashStringHelper *fstr) const { return equals(fstr); }

There isn't a version of equals accepting a flash string, so it will copy-construct it to a String, like it also does now. But at least it will not generate code for this copy construct every single time it is called.
So this will not affect performance, but at least it will generate smaller binaries.
Even better would be to have a version of the equals function with a flash string as an argument, so you won't even need to copy it.

Just to give an example of what is implemented for the startsWith function, in the .h file:

    unsigned char startsWith(const __FlashStringHelper * prefix) const {
        return this->startsWith(String(prefix));
    }

Since it is implemented in the .h file, it is rather useless as it does generate the same (inline) code as the compiler would if only the function existed with const String& as argument.
By moving this to the .cpp file, you actually reduce the build size as the cast to String is then only added once to the binary.

@earlephilhower What do you think of such optimizations?
You could even wrap them in a define so people not using the String class a lot will not see an increase of the String object, but for those using it a lot, will see a (sometimes) significant drop in binary size.