Compiler optimization levels vs optimization pragmas

General
1

I getting caught up on the latest release of Xojo and see that compiler optimizations were added to 2016r3 — Great! What I cannot find* is any info on how these new compiler settings compare to the previous optimization pragmas:

#pragma BackgroundTasks FALSE
#pragma BoundsChecking FALSE
#pragma StackOverflowchecking FALSE
#pragma NilObjectChecking FALSE

I sprinkle these pragmas all over my code, but when I need to debug a hard crash, I must do a global find-and-replace to replace FALSE with TRUE. I’d love to be able to get rid of all these pragmas if the new compiler optimization settings make them redundant.

*Searching the forum is a bit tough because I can’t sort search results by date. I tried searching and looking through posts since 2016r3, but the results are not in sequential order—sorry if this is a duplicate post!

2

These are apples and oranges - the #pragmas should be thought of as “framework-code-generation” options, which happen at a higher level than the compiler options, which happen at a much lower level.

Also, BackgroundTasks is very different from the other 3 pragmas, as it affects thread / yielding behavior. Turning it on or off can have dramatic effects if you are using threads at all.

3

change those pragmas to this

#If Not DebugBuild
#pragma BackgroundTasks FALSE
#pragma BoundsChecking FALSE
#pragma StackOverflowchecking FALSE
#pragma NilObjectChecking FALSE
#endif

this way they only take affect when you COMPILE, and disables them for debugging automatically

And these have nothing to do with the “compiler optimizations” that were added…

4

Very informative; thank you both! I can’t believe I didn’t think of #If Not DebugBuild.

Yes, the BackgroundTasks pragma can adversely affect runtime behavior and is not something I would expect from a compiler optimization; I’m glad I asked. :slight_smile:

5

They’re apples & bananas (not oranges since both apples & oranges are kind of ‘round’)
These are two different but semi-related things (apples & bananas are both fruits but the similarity stops there)

Compiler optimizations are for code optimization (loop unrolling, etc)

The pragmas are for code generation (do we include code to check bounds, check for nil etc)

Code is normally generated and then compiled and optimized

These things are complimentary and their effects cumulative - its not a binary choice between using one or the other

6

My use is as follows in most projects:

#pragma BackgroundTasks False - used in many functions where I want the function to behave Atomically and not yield during threads. Especially useful when you have a small tight loop and yielding causes a big performance hit.

#pragma BoundsChecking, StackOverflowChecking, NilObjectChecking - I almost never turn these off - the only exception would be calculation code that has to run at top speed and it’s really been reviewed to be rock solid.

I generally do not have different settings for my Debug vs Build apps, as I find that this can cause subtle differences in behaviors between the IDE and compiled apps that are very hard to isolate.