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.