Total Flash memory is lower compared to mbed-cli

[ladislas]

I've been playing with mbed-cmake and I really like what you are doing. It integrates well in my project and gives me a lot more flexibility.

One thing I just noticed: when compiling the same main.cpp with mbed-cmake and mbed-cli, for release profile, mbed-cmake gives a smaller .bin.

I have not yet tried to run the program on my board, will do so tomorrow.

The program:

#include "mbed.h"

BufferedSerial serial(USBTX, USBRX, 115200);

int main() {

    while(true)
    {
        char const message[] = "Hello world!\n";
        serial.write(message, sizeof(message));
        ThisThread::sleep_for(1s);
    }
}

mbed-cmake output:

$ cmake -DCMAKE_BUILD_TYPE=Release ..
[...]
Displaying memory map for leka_os
+------------------------+-------+-------+------+
| Module                 | .text | .data | .bss |
+------------------------+-------+-------+------+
| CMakeFiles/leka_os.dir |   126 |     4 |  832 |
| [fill]                 |    83 |     8 |   25 |
| [lib]/c.a              |  4840 |  2108 |   89 |
| [lib]/gcc.a            |   760 |     0 |    0 |
| [lib]/mbed-os-static.a | 30107 |   444 | 8066 |
| [lib]/misc             |   216 |    12 |   28 |
| Subtotals              | 36132 |  2576 | 9040 |
+------------------------+-------+-------+------+
Total Static RAM memory (data + bss): 11616 bytes
Total Flash memory (text + data): 38708 bytes

[100%] Built target leka_os

mbed-cli output: (program created with mbed new prog)

$ mbed compile --profile mbed-os/tools/profiles/release.json
[mbed] Working path "/Users/ladislas/dev/tmp/vs2" (program)
Building project vs2 (DISCO_F769NI, GCC_ARM)
Scan: vs2
Compile [100.0%]: main.cpp
Link: vs2
Elf2Bin: vs2
| Module             |     .text |    .data |      .bss |
|--------------------|-----------|----------|-----------|
| [fill]             |    98(+0) |    3(+0) |    29(+0) |
| [lib]/c.a          |  4852(+0) | 2108(+0) |    89(+0) |
| [lib]/gcc.a        |   920(+0) |    0(+0) |     0(+0) |
| [lib]/misc         |   188(+0) |    4(+0) |    28(+0) |
| main.o             |   112(+0) |    0(+0) |   832(+0) |
| mbed-os/components |    46(+0) |    0(+0) |     4(+0) |
| mbed-os/drivers    |  2762(+0) |    0(+0) |     0(+0) |
| mbed-os/events     |  1498(+0) |    0(+0) |  3104(+0) |
| mbed-os/features   |  2000(+0) |    0(+0) | 12796(+0) |
| mbed-os/hal        |  1588(+0) |    8(+0) |   130(+0) |
| mbed-os/platform   |  4822(+0) |  260(+0) |   420(+0) |
| mbed-os/rtos       | 10332(-4) |  168(+0) |  6220(+0) |
| mbed-os/targets    | 14154(+0) |    9(+0) |  1308(+0) |
| Subtotals          | 43372(-4) | 2560(+0) | 24960(+0) |
Total Static RAM memory (data + bss): 27520(+0) bytes
Total Flash memory (text + data): 45932(-4) bytes

Image: ./BUILD/DISCO_F769NI/GCC_ARM-RELEASE/vs2.bin

How could you explain such a difference?

On a side note, would it be possible to have a more detailed size output with mbed-cmake?

On a second side note, compiling with mbed-cmake (on macOS), doesn't use the CPU as much. With mbed-cli, my macbook pro is quickly heating and the fans have to be turned on.

So if mbed-cmake saves space and battery, it's a big win!

[multiplemonomials]

How could you explain such a difference?

If I had to guess, it's likely due to mbed-cmake providing a default mbedignore that removes a lot of the mbed os code for additional features. In the standard mbed-os build these are always enabled by default, though the linker is supposed to discard the code that isn't called in the final binary.

You could try copying the .mbedignore and mbed_app.json from the mbed-cmake/mbed-src folder into mbed-os/ and run the MBed CLI build again. If the results are still different, then I don't really know what the reason could be.

On a side note, would it be possible to have a more detailed size output with mbed-cmake?

Not easily, no. It would require modifications to the size printing script and I'm not very familiar with how that works. And it might not be possible because cmake builds mbed-os's object files differently.

On a second side note, compiling with mbed-cmake (on macOS), doesn't use the CPU as much. With mbed-cli, my macbook pro is quickly heating and the fans have to be turned on.

If you just run make with no arguments, then it will only perform a single-core build which runs slowly. This might be why it's using less CPU. You can use make -jn (where n is the number of CPU cores on your machine) to run multicore make that executes faster (this matches how the MBed build system works by default). You could also use the Ninja build tool which runs the optimum number of parallel jobs automatically.

[ladislas]

You could try copying the .mbedignore and mbed_app.json from the mbed-cmake/mbed-src folder into mbed-os/ and run the MBed CLI build again. If the results are still different, then I don't really know what the reason could be.

I'll wait for https://github.com/ARMmbed/mbed-os/pull/13281 to be merged to do more benchmark.

[ladislas]

You could also use the Ninja build tool which runs the optimum number of parallel jobs automatically.

And I've just tested Ninja... boy that is fast!

[multiplemonomials]

Have you gotten a chance to do this comparison yet?

[multiplemonomials]

Also @ladislas I noticed that you figured out how to add custom target support in your repo. Would you mind if I merged that support back into the master copy here?

[ladislas]

@multiplemonomials no I haven't investigated more, I had a lot of things on my plate. At the same time, we haven't encountered any issues since using mbed-cmake, so that's good news.

Also @ladislas I noticed that you figured out how to add custom target support in your repo. Would you mind if I merged that support back into the master copy here?

Yes, please do! Let me know if I can help.

[ladislas]

I'll close for now and open again if needed in the future.