[MLton] commit r4134: fixed fix to getrusage bug

[Matthew Fluet]

>>     val MLton.GC.setRusage: bool -> unit
> ...
>> However, this function was never used in the basis library.  In
>> particular, we never enabled rusage when MLton.Rusage.rusage was used.
>> This further meant that Timer.getGCTime would _always_ return zero,
>> unless the user happened to run with gc-summary or gc-messages (or
>> used the corresponding MLton.GC functions).
>
> The fix to GC_setRusage looks correct.  But the fix to
> MLton.Rusage.rusage looks incorrect.  It was intentional to not call
> "MLtonGC.setRusage true" there.  The problem is that this includes all
> the getrusage calls (with noticeable performance cost) just because
> rusage occurs in the program.  The intent is to have the programmer
> specify at run time whether or not he wants the information gathered.
> For example, we do this in MLton with a line in main.fun:
>
>   val () = MLton.GC.setRusage (!verbosity <> Silent)

Fair enough, but I'd still prefer to see it automatically enabled when the 
Timer structure is used.  It's rather odd behavior to not get the GC 
timing information unless the program is invoked with particular @MLton 
flags or using the MLton.GC structure.  In particular, you can't write 
portable SML code that uses the Basis Library with predictible effects on 
multiple compilers.  (Admittedly, GC time is very implementation specific, 
but still, if I want to have the program itself include a summary (rather 
than the summary of the host compiler/interpreter), then I prefer not to 
need compiler specific details.)