The sather compiler can be slow, especially if you don't have enough memory or use a lot of class parametrization. What follows is mainly from a posting by Matt Kennel, a long-time Sather user. The timing results are with respect to the 1.0.7 release, but the syntax for the compiler options has been updated to 1.1.
Most importantly, have enough physical RAM. 32MB is much superior to 16 MB. 32 should be enough for most things, except perhaps recompiling the compiler again. Netscape is a memory hog. Quit it. Besides, you have to do real work sometime.
Secondly, the default compiler flags are not tuned to make the fastest compilation, but to generate the fastest or safest executables. Do not use "-fast" until the final production stages: the loop and subexpression optimizations are surprisingly slow and memory-consuming.
In the initial phase of getting a program running, when you are just looking for compiler errors, the following option is extremely useful:
-only_check -- Just report errrors, do not generate any codeUsing this option means that the compiler does not have to generate code, so it will use less memory and get to your errors much faster.
In the next phase, when debugging a program, generate a progam with checking on by using the options
-chk_all -- Turn on all checking - slows down resulting -- executable, but it should never crash -debug_source -- Debugging with source line numbersNote that all the -debug options reduce incrementality considerably since whenever source line numbers change slightly (even though the generated code remains the same), a lot of recompilation must take place
To get extra debugging information, such as a full backtrace of the stack whenever a crash occurs, use the option
-debug -- More debugging informationUnfortunately, this explodes the executable size to an extent that you might find unacceptable.
Here are the flags that are useful for making production quality i.e. non-checking, optimized programs quickly.
-only_reachable -- Alternatively, since unreachable code
-- is only checked after the executable is
-- generated, you can kill the compile when
-- it says ``Checking unreachable...''
-O_inline_routines 30 -- These strongly help executable performance
-O_inline_iters 30 -- but don't add much to compile time.
-replace_iters
-chk_no_void all -- Turn off expensive checking options
-chk_no_bounds all
-chk_no_pre all
-chk_no_assert all
-output_C -- This is VERY important! If you don't
-- do this you will never get incremental
-- C compilation.
If you are strapped for memory or VM space consider using '-only_C'
and then do a manual "make" of the generated C code. This might save
some extra swapping above -output_C.
Ben's note: These timing results were with the 1.0.7 compiler
I (Matt Kennel) have a medium sized 'chaotic data analysis' program for my research. It uses most Sather features except for exceptions. It comprises about 8 to 10 thousand lines of code, disregarding those portions of the standard library called. (The Sather library is all source so it does matter). With the above options the Sather portion of the recompilation takes 25 seconds of wall clock time on my reasonably contemporary machine: 120 Mhz Pentium, 32 MB RAM, Linux. I don't think this is awful, though not extraordinary. A full C compilation (no incrementalism) takes probably another minute or two. I use the resulting binary in numerical production runs. If the incrementalism is working OK (and your C compiler is not slow) performance is not bad, you might have to recompile only one or two major C files at at time.