Bad compile-time and run-time performance when using STM32CubeIDE compiler

[Armandas]

I am preparing for migration from SWSTM32 V2.4 (GCC 6.3.1) to STM32CubeIDE V1.4 (GCC 7.3.1).

During testing, I have noticed very significant performance issues in both compile time and generated executable run time. Please see the attached table for my test results.

All tests were done using CMake and changing the compiler path, so there is no effect of different IDEs.

NOTE: I was not able to test the generic ARM toolchain bundled with STM32CubeIDE, due to it not being able to find a header <bits/c++config.h>. I, therefore, downloaded GCC 7.3.1 form ARM for this comparison.

Run times are in seconds.

[TDK]

I understand "build time", but what is "executable run time"? Are you timing how long a program on an STM32 chip takes to run?

Make sure you have parallel build enabled, or at least equivalent between the options.

[Armandas]

Yes, the run time is the time is takes for my test program to run on the MCU. The timing has been taken using an oscilloscope.

Parallel build was enabled for all tests.

[TDK]

Not sure. I switch between whatever STM32CubeIDE uses by default and "GNU Tools Arm Embedded\9 2019-q4-major" and haven't noticed a difference.

[Armandas]

I re-took the GCC 7.3.1 tests with the parallel build disabled and got the following results:

ARM GCC 7.3.1: 1:48.07

ST GCC 7.3.1: 8:28.49

The difference is staggering...

[Ozone]

But it's free ... :-J

You get what you pay for - if you ever heard that proverb.

[Armandas]

Thanks for the great answer...

I'm not here to complain - I can fix the issue by using an external toolchain and forget about it.

By reporting a potential issue in the ST toolchain, I'm trying to help the community. I doubt ST is interested in providing inferior tools...

[Ozone]

While a bit tongue in cheek, it was a honest answer.

The free CubeIDE is targeted at the beginner and hobbyist, where performance is secondary.

Maintaining a toolchain and optimize it for a variety of targets is time consuming, and requires experience and expert knowledge.

ST obviously values the number of supported MCU variants highest, then perhaps bugfixes.

It is what it is. Some other vendor-specific toolchain are not different in this regard.

[mattias norlander]

Hi @Armandas​,

@Ozone​, is right in that there are tools that in many cases provide better code size and execution speed performance than GCC in general.

What is puzzling is the extremely poor build time performance your benchmark shows. We already know since before that GNU Tools for STM32 is about ~30 slower the GCC for ARM on Windows. The reason for the anticipated ~30% slow-down is that our toolchain supports long paths (one of the patches not part of GCC for ARM). This has been a huge source of problems in the past since many example projects have "deep folder hierarchies" and customers are allowed to place the Cube repository anywhere... But your trials are showing ~300%. That is not expected.

I assume this is on Windows only? If you ran on MacOS/Linux the compile time should be ~identical between GNU Tools for STM32 and GCC for ARM.

We have made a fix for make/busybox to try to resolve the parts of the "30% slow-down", but there are still remaining fixes to be added in other places of the toolchain code.

Could you try importing instead some large example project from the CubeFW packages and build that and compare build times ARM vs ST? Do you always get this result? Maybe we could compare the same example projects on two different environments to see if we see the same result?!

Your code execution speed result also looks on the poor side. Impossible to say why without looking at your code...

Thanks for providing your feedback!

[Armandas]

@mattias norlander​ 

Thank you for the answer. I have tried a few things as suggested.

Building the above project on a Linux machine, I got identical results with ST GCC 7.3.1 and ARM GCC 7.3.1.

Back on Windows, I tried to build some different projects:

• Another (smaller) project:
  • ST GCC: 31 s
  • ARM GCC: 12 s
• TouchGFX Demonstration from CubeFW:
  • ST GCC: 65 s
  • ARM GCC: 42 s

The TouchGFX example does not appear to be impacted as much as our internal projects.