profiling

[Stephen Weeks]

> 2. modified gc.c to update ru_gc appropriately (i.e., perform
>    getrusage(RUSAGE_SELF, &ru_start) just before the gc, perform
>    getrusage(RUSAGE_SELF, &ru_finish) just after the gc,
>    and set  ru_gc = ru_gc + (ru_finish - ru_start),
>    where I've defined appropriate rusagePlus and rusageMinus functions).
>    So, we now record all resource usage of the garbage collector, not just
>    time.  The gcTime is still there and updated during a gc, but it will
>    (almost) always correspond to the time derived from the data in ru_gc.
>    (There might be some rounding cases where they will differ, but it
>    should be negligible; and we could avoid it by always resetting gcTime
>    to the time derived from ru_gc, rather than incrementing it with the
>    time derived from (ru_finish - ru_start).)

Why not get rid of gcTime from GC_state and get rid of MLton_gcTime, since its
functionality is now superseded by MLton_RUsage_ru.

> 4. added /src/basis-library/mlton/rusage.{sig,sml}
> 
> signature MLTON_RUSAGE =
>    sig
>       type timeval = {sec: int, usec: int}
>       val toTime: timeval -> Time.time
>       type rusage = {utime: timeval, stime: timeval}
>       val rusage: unit -> {self: rusage, children: rusage, gc: rusage}
>    end

I'd like to stick with the 'type t' convention in the MLton libraries.  Also,
why not just use Time.time from the basis library instead of timeval?  So,
rewrite the above as:

signature MLTON_RUSAGE =
   sig
      type t = {utime: Time.time,
		stime: Time.time}

      val rusage: unit -> {children: t,
			   gc: t,
			   self: t}
   end

> 6. modified /src/lib/mlton/basic/time.{sig,sml} to use
>    MLton.RUsage.rusage.  It converts the {sec usec} record into a
>    Time.time and will ditch any extra fields in the rusage that we might
>    add later
>    modified /src/lib/mlton/basic/{process,trace}.sml to use the new type
>    of Time.times

I missed something.  Why did the type of Time.times change?

> 7. modified /src/basis-library/posix/proc-env.sml to revert
>    Posix.ProcEnv.times back to it's original definition.

I'd like to see Posix.ProcEnv.times using Rusage.rusage, based on the reasons
Henry gave earlier.

 I  would  definitely  vote for getrusage() over times().  My argument is that
 the former is in seconds/microseconds while the latter depends on the  length
 of  time  in  a  clock tick which is goofy.  This rounding problem could have
 caused the problem as Matt said.

 Note, the number of tiks per millisecond doesn't have to be an integer and in
 fact  historically wasn't.  The traditional value was 60 Hz, so 1000/60 ticks
 per millisecond.

Also, as Henry said, in Linux, times is implemented in terms of getrusage
anyways.

> 8. modified /src/mlton/codegen/x86-codegen/x86-mlton.fun
>    to reflect change in offset of gcState.canHandle

This reminds me that it would be nice to have a way of automatically generating
such constants that are used in the backend.