Waverly wrote:

>> Call1(), Call2() and Call3() below produce identical assembler when
>> compiled 'Fastest, smallest', despite having 2, 1 and 0 temporary
>> variables in the source.
>
> I keep my settings on "fastest". I have never really understood
> the option of "fastest, smallest".  It would seem to mean the compiler
> will make the smallest binary it can while maintaining X level of  
> speed.
> Whereas fastest will make the absolute fastest binary possible without
> regard for how large the binary will become.  Given those definitions,
> if they are correct, the "fastest, smallest" may not be the fastest
> option, but the fastest within unknown size constraints.
>
> Would that be a fair assessment of "fastest" vs. "fastest, smallest"?

It's as good a description as I have read. In practice it is rare to  
get worthwhile benefit from 'Fastest'.

Many apps do not need optimizing for speed at all. Others, though time- 
critical, spend most of their time in library (toolbox) routines and  
are therefore little affected by optimization level. Measurements  
provide a base for choosing the 'right' level for your app.

As an example, I measured the effect of optimization level on FBtoC's  
compilation time, size of the executable, and performance (time to run  
a task, taken as the best of 3 consecutive runs). The task was FBtoC  
translating its own source code. The compiler was gcc 4.0. Times are  
in seconds.

                       compile    size     run
-O0 None                6.80    631 KB    1.20
-O1 Fast               11.24    508 KB    0.73
-O2 Faster             15.44    520 KB    0.68
-O3 Fastest            17.02    532 KB    0.68
-Os Fastest, smallest  15.23    479 KB    0.71
-Oz Smallest           15.54    422 KB    0.74

FYI, releases of FBtoC are 'Fastest, smallest'. The FB5 editor is  
'Smallest'.

Robert P.