execution speed debug vs release?

[muz]

I'm terribly sorry for cross posting - I am just finding my way around and have already posted this question on the xmos support forum, however this community seems to be the best place to put my question.

I'm trying to develop some code to run on an XC-2 board and during debugging I'm using a test output port (ref clocked, so 100MHz) which I am toggling and examining on an oscilloscope. I found that if I build my code for debug, I get much slower execution with some things than building for release. In particular doing an input from a timer seems to be pretty slow in debug. For example;

Code: Select all

p_test <: 1;
p_test <: 0;

produces a 10ns pulse in release mode as expected, but in debug this is a 30ns pulse.

If I add a timer input operation in between the two port outputs, like;

Code: Select all

p_test <: 1;
t :> timeval;
p_test <: 0;

In release mode this outputs a 20ns pulse (again as expected), but running a debug build this produces a massive 110ns output pulse, so the timer input operation is taking much longer than expected. The port and timer are both clocked using the 100MHz ref clock, so I am a bit confused as to what is going on here, whether optimisations are coming into play or something else.

Am I missing something big here, or is there a really significant performance penalty when trying to debug stuff?

[Jerry]

Take a look at the disassembly to get an idea of the differences between debug and release modes. When building for debug, the compiler generates a lot of redundant code that gets optimized away when you build for release.

[tyler]

Take a look at the disassembly to get an idea of the differences between debug and release modes. When building for debug, the compiler generates a lot of redundant code that gets optimized away when you build for release.

Is this only due to the fact that the default optimization level for debug is -O0 while for Release it is -O2?

In other words, if my project is in a Debug configuration with optimization set to -O3 and debug symbols set to a minimum, is it running as fast as it can -- or is it still pulling in some debug stuff that slows things down (a la Visual Studio, etc). Is "Debug" just a name -- or is there more to it?

Thanks,
Tyler

[Jerry]

One problem with debugging code built with optimisation levels set higher than -O0 is that code often gets optimised to the point where it's hard to set breakpoints and step the code.

I normally build "debug" targets with the default optimisation setting of -O0 for this reason and switch to "release" with optimisation on for final testing after wringing most of the bugs out of the code. In is important to do your final testing with optimisation set to whatever you intend to release the final code with to catch any timing issues related to optimisation.

[muz]

Thanks for the replies.

I hadn't yet gone to the extent of comparing assembly output, and I suppose it would be good to repeat my little pulse output test in debug with -O2 or -O3 and time how long it takes to answer the "extra debug stuff" question.