-
Notifications
You must be signed in to change notification settings - Fork 836
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
In search for RAM to save, why use ints instead of defines? #1849
Comments
You are under the impression that these takes RAM? Do you have anything that shows that is the case? There is explanations on why DEFINE is not used and should be avoided. As well as previous issues on this same topic. (I will add references to these in a bit) |
I believe we have tried this before. Please see the rest of #1493 for other efforts we've tried.
Yes, there is. As defined contants vs. defines, you're able to do type checking on them. It is also part of the style guide we use. They are not really in an object per se. Well, not as I understand it. The compiler does the right thing. They are not included if they are not used, and the don't take up SRAM.
Feel free to. If it can be proven to save space, I'll certainly look into it.
I suggest you try for yourself, but I've already tried similar and it didn't save anything. But as I said, prove it works and I'll be all on it. |
So after that (much better explanation then mine) I will now propose we close this. But are totally ready to reopen, if numbers can be shown that this would make any difference. |
Thanks for the links. |
I'll add (to be clear on what we expect) if built with debug flags enabled it might have an impact (but we won't optimize that) However in general, builds are not and these consts are optimized and you would not see any difference. |
I wish them well. If you look at those links and the comments from @mcspr . They point out how to use the gdb to look at the actual instructions built/compiled and it can determine where a variable or constant is located. i.e. Ram or Flash. It's been a while since I delved into it. But if I recall correctly, I looked into it and the But hey, it's been a while. I could be remembering wrong and/or things have changed etc. |
+1 to 'gdb'. Here it is useful as an interactive 'objdump', 'nm', 'readelf', etc. all in the same box. And on case-by-case basis (...preferably, not to go cross-eyed...). Compiler sees the whole code, then optimizer and then the linker get their pass at the code. You may also run into the case where value is inserted as part of the machine code. Another one is C++ is not C, rules may vary between the two when dealing with 'const'ants and 'constexpr'essions. |
Interesting blogpost! |
OK, got feedback from this user with an already predicted result... So this can be closed. |
Okay, that was an unexpected result. Thanks for the confirmation. |
In my endless quest to save RAM in my project (ESPEasy) I came across this section of the code:
IRremoteESP8266/src/IRremoteESP8266.h
Lines 1112 to 1388 in 85d587f
These are all
const uint16_t
and I wonder why these need to be C++ objects instead of defines.As objects they take RAM, where as defines they are just numbers in the code.
So I was wondering, is there a specific reason for having them as an object?
If not, would you appreciate a PR to convert these?
I have not tried it yet, but my guess is that it would save roughly 550 bytes of RAM and maybe also reduce the build size slightly as a bonus.
The text was updated successfully, but these errors were encountered: