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.

[Armandas · Accepted solution]

I think I got down to the bottom of this.

I was able to get the build time down to ~42 seconds, by making all the include paths absolute and removing almost all -I include path parameters from GCC build commands. I guess the long path support overhead is increasing with each include parameter.

By the way, the ARM GCC build time went down to about 20 seconds.

[mattias norlander]

Does your project (the original one this topic was started on) contain many include paths?

The benchmark on the TouchGFX demo sounds maybe still a bit higher than what we have observed, but more reasonable than the ~300% increase...

Which CubeFW package did you use and which board example? Please point me to it like this:

C:\Users\norlandm\STM32Cube\Repository\STM32Cube_FW_F7_V1.16.0\Projects\STM32F7508-DISCO\Demonstrations\TouchGFX

Then I can run comparison between ST and ARM GCC on my computer on Windows.

[Ozone]

Interesting to hear.

Having Windows environments at my company and Linux at home, I never saw such a huge difference in compile times, just from path resolution.

Perhaps some Eclipse issue ?

Or does Cube use a Unix emulation layer like Cygwin ?

[MM..1]

Hello, you dont write on how disk your gcc and source is stored, how file sytem, have you antivirus enabled ...

My TouchGFX project around 700kB linked took 12s on SSD NTFS , but on network share 90s

[Armandas]

Yes, as I posted above, removing the include paths basically resolved the issue...

Here is the demonstration I used:

C:\Users\owner\STM32Cube\Repository\STM32Cube_FW_F4_V1.24.2\Projects\STM32469I_EVAL\Demonstrations\TouchGFX

[mattias norlander]

Hi,

CubeIDE does not use any Unix emulation.

But when using relative paths they have first to be converted into absolute paths before it can be expressed as an UNC path. So relative paths should introduce some delay. GCC Arm does not require UNC paths since it does not support long paths. So the UNC conversion step in theory should introduce some delay on the GNU Tools for STM32 vs GCC Arm.

Nevertheless the original results presented above is way worse then our benchmarks.

Regarding "execution time on target" GNU Tools for STM32 vs GCC Arm, we do expect a little bit slower execution speed in the ST toolchain because of:

• GNU Tools for STM32 newlib standard library is optimized for size -Os, regardless of the project optimization level
• GNU Tools for STM32 newlib nano library is optimized for size -Os, ...
• GCC Arm newlib standard library is optimized for size -O2, ...
• GCC Arm newlib nano library is optimized for size -Os, ...
• Additionally GNU Tools for STM32 sets more defines for both newlib variants to improve code and RAM size

And as we know smaller code (fewer instructions) tend to effect execution speed in a negative way.

If this makes up for the full difference? ... Hard to tell...

[Ozone]

It is also possible (and not really difficult) to mess up a Windows machine's registy, especially over time.

If I'm not mistaken, environment variables (often used for paths) are stored there.

Not to mention the common Windows ailments like fragmented file system and RAM.

[Cartu38 OpenDev]

Please be aware 2 toolchains are STM32CubeIDE supported. Both are GCC ones. One is GNU ARM embedded, second is ST improved one especially thinking long path support. As such long path support may have some performance drawbacks if long path not required to you always possible to rely on native proposal ...

See project properties then C/C++ Build > Settings ​> Toolchain Version

[Pavel A.]

@Ozone

Eclipse CDT seems to be quite robust and smart, it's Windows support is first class.

But be sure to have a good SSD and enough RAM.

-- pa