8 years, 11 months ago.

Offline compiled code slower and larger than using online compiler

Hi All,

I have exported my project (using LPC1768) into LCPExpresso. The project is somewhat math heavy, using mostly float and some double, some trigonometric functions, a little bit of printfs. Getting it to compile and run using LPCExpress was pretty straightforward, I just followed the instructions for the offline tool chain.

I have noticed that the code size is approximately 2x of what the online compiler is producing and that it also runs approximately 30% slower. Very similar results in both release and debug mode. I have tried to play with most of the compiler settings, with no significant impact. In fact, instead of using the exported mbed library object file, I tried building the entire mbed library from the source code, with no real difference as compared to the object mbed lib.

Looking at the map file, a few of the trigonometric functions take quite a bit of space in the binary, similarly some versions of the printf apper rather large. I did not really see much dead code in the map file, so I am guessing an unused code is being eliminated properly by the linker.

My guess is that the standard libc libraries which come with the LPCXpresso GCC are not as good as those used by the online compiler, or that the online compiler is using some settings which make the code smaller and run the floating math faster - perhaps some faster float model. I did not profile other generic code to see how well it runs.

I was wondering if anybody has any relevant experience even with other offline tools. Is there a way to match the online compiler code performance or to get the libc it is using?

Thanks a lot

Pavel

Question relating to:

1 Answer

8 years, 11 months ago.

As far as I know, the online compiler uses armcc with optimization level -O3. So if you use MDK-ARM (uVision) locally with optimization level -O3, I think you should see similar performance. You could also try -O3 using GCC (normally, "release" corresponds to -O2).

Aksel, thanks for your answer. MDK-ARM appears to behave as you suggested, at least when it comes to the reported binary size - too bad the full version is so expensive and my project is already beyond the 32k limit. Now I am even more convinced that it is the quality of the standard libraries making the size/speed difference.

posted by Pavel Novotny 07 May 2015