sketch using 2.4.0 is more than 30 kB larger than 2.3.0 #4172
Comments
|
I just built it against GIT head and got your #s for LWIP v1.4 precompiled w/in epsilon: The top ~100 symbols in size are: |
|
In 2.3.0 I again get your #s: Looking at the top 100 symbols shows: |
|
New library routines were included in 2.4: ...and others... Looks like two smoking guns: strtod/dtoa, and floating point functions were included in 2.4 in the main core libraries! Not sure there's a good reason to have floating point in the core proper... |
|
Actually, now that I think about it, I do know why. Moving from the SDK libs to newlib.c added floating point format support to printf, which was a big sticking point for lots of folks. Therefore, any scanf()/printf() now supports %f by, you guessed it, importing the floating point math library and the floating point string parser... |
|
Here are the numbers for my real application: ` 2.4.0 830271 45820 I certainly use tons of FP and do hand-stands to avoid sprintf %f. Are you saying I can now start using %f and not expect the program to grow much? |
|
-edit- re-read your commend properly. sprintf/sscanf %f is already paid for, there should be no increase AFAICT. |
|
You may also want to run the readelf -a commands I listed above on your real app to see if there's something else not accounted for... |
|
changing all dtostrf to %f reduced 2.4.0 size by 1k: 830271 -> 829719. But it's still 30k bigger than 2.3.0: 800313. Since they both included or pulled-in %f I don't think that's the reason. I'm almost more worried by the 1.3k increase in precious RAM used in 2.4.0: 44556 -> 45824 |
|
Duplicate of 4089. Closing. |
|
Isn't there an argument to be made that everyone shouldn't suffer the flash and memory increases for including floating point support by default. (Does the ESP8266EX even have floating point hardware?) There are possible designs where floating point is avoided within the ESP8266 altogether (because it is a performance hit). I have seen many code sequences where floating point is avoided by using fixed-point or simply refactored the floating point computations to another node (like web browser) which is more likely to have floating point support. |
|
I think FP is a red herring. The code is larger for some other reason. |
|
yes, usually linker only include actually called/used routines into final binary. |
|
@pidloop Is it really a red herring? If printf / scanf supports %f, how could the linker ever remove float formatting/parsing support? |
|
On Sun, Jan 21, 2018 at 11:36 AM, emontnemery ***@***.***> wrote:
@pidloop <https://github.com/pidloop> Is it really a red herring? If
printf / scanf supports %f, how could the linker ever remove float
formatting/parsing support?
Because my sketch is about 30 kB larger whether I use dtoa/strtod or
printf/scanf with %f.
|
|
Thought I would post my current sizes and sorted linker sizes. First uses 2.3.0, second uses 2.4.0 with lwip 1.4 precompiled. I am not using %f anywhere. Again, note the size is about 30 kB larger with 2.4.0. The complete project is hosted here Thank you. |
ghost
reopened this
|
Something that popped out at me: Anyone know why a function like this could grow over 1KB? There are others that grew, but usually only a few bytes. |
|
The compiler doesn't know if you use %f in a string, so you have to use the linker options, @pidloop , to remove the printf_float/scanf_float bits. @devyte I think you have the versions backwards. 2.4 is 2898 bytes, 2.3 is 4058. We saved 1KB here. :) |
|
@earlephilhower oops you're right, the windows editor I used opens the panes in reverse order to what I'm used to |
|
My two bobs worth. But can anyone explain why there is so much space used for Raw "un-displayed" text. It makes me want to use single letter function names and keep all the libs in a short folder name off root. Can any smartie tell me how to remove all the "junk" from a compiled file.? |
|
@Hiddenvision compile with NDEBUG, -Os options, strip resulted elf. and you will get rid of it |
|
@romansavrulin, Cheers been using that for a while and it removes a little more.. The FULL path names are still there, Actually I realise that my own strings of words are wasting far more space than anything else. But to be honest, now that I can OTA <= 1024k, Hv. |
|
All of these suggestions are completely missing the point. The exact same program compiles 30k larger on 2.4 than 2.3. The question is whether this is intentional (and if so why) or whether there is something wrong and needs to be corrected. Work arounds are NOT the answer here. |
|
Not sure where you're going with this, @pidloop, but the code size change, in certain sketches, is the result of intentional decisions to add requested support in the standard libraries. There is nothing wrong that needs to be corrected. However, there are obviously some sketches in which this causes them to cross some line making them hard/impossible to OTA update. In those cases, the workarounds above will get you as close as possible to old behavior. If you really are in a tight bind, then you can always stick with 2.3.0. |
the 500k limit is not a problem now but nobody wrapped in the edits to the ld files and boards.txt.py on 2.4.1. To be honest I have not given this any thought since I remapped the flash. Hv. |
|
My point is if the increases in 2.4 are well thought out and intentional then that's fine. I just wanted to encourage the maintainers to beware of unintentional code creep. Since all the discussions I have seen simply try to explain or mitigate the increase, rather than admitting it might need more thought, I can only assume the maintainers believe this increase in default size is justified and I will (must) accept their judgement. Regarding OTA, after switching to 4M(1M SPIFFS) this is not an issue for me any longer. Thanks. |
|
Glad you're OK now! I believe this tracker can be closed now. The fact that code grew in some cases was shown, the reasons behind it explained, and several mitigation options were listed including @d-a-v's script (which is now in the repo) to remove %f format support. |
While working on issue #(4166) I noticed the compiled size of the test program I was using grew by about 34 kB and RAM usage grew about 1.4 kB in version 2.4.0 compared with 2.3.0. While this is not a critical issue, the sudden jump is a concern. Note there was only a very small increase from 2.2.0 to 2.3.0. I wonder if there is a particular reason for this latest increase and whether some way might be found to reduce it.
My application ( here ) already uses about 850 kB and I am hoping to add more features so the loss of 34 kB may eventually become significant.
Here are the sizes reported after setting the ESP Huzzah Board version, using the toy sketch below:
`
#include <stdlib.h>
#include <string.h>
#include <math.h>
#include <SPI.h>
#include <ESP8266WiFi.h>
#include <WiFiServer.h>
#include <WiFiClient.h>
#include <WiFiUdp.h>
char ssid[] = "clearskyinstitute";
char pw[] = "from651plan";
void setup()
{
Serial.begin(115200);
}
void loop()
{
prWiFiStatus(WiFi.status());
}
void prWiFiStatus (int s)
{
#define VALCASE(x) case x: Serial.println(#x); break;
}
`
The text was updated successfully, but these errors were encountered: