profiling

[Matthew Fluet]

> 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.

Fine with me.  I only kept it in for compatibility.

> 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

That's easy enough.  My motivation for the former was match getrusage as
much as possible.  Principally, as Henry pointed out, rusage gives you
sec/usec -- and while the MLton implementation of Time.time does have usec
granularity, there's nothing in the Basis spec that requires it (although,
{to,from}Microseconds suggests it).

> > 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?

The old version of Time.times was:
      type times =
	  {
            cstime: t,  (* system time of terminated child processes *)
            cutime: t,  (* user time of terminated child processes *)
	    gc: t,      (* gc time of process *)
            elapsed: t, (* elapsed system time *)
            stime: t,   (* system time of process *)
            utime: t    (* user time of process *)
          }
(which reflected the Posix.ProcEnv.times function), and the new version
is the following:
      type times =
	  {
	    self:     {utime: t, (* user time of process *)
		       stime: t  (* system time of process *)
		       },
	    children: {utime: t, (* user time of terminated child processes *)
		       stime: t  (* system time of terminated child processes *)
		       },
	    gc:       {utime: t, (* user time of gc *)
		       stime: t  (* system time of gc *)
		       }
	   }
(which reflects the MLton.RUsage.rusage function).

I guess there's no reason that it had to change, but I thought that
exporting the finer grained gc timing would be useful.  And nothing in the
compiler libraries looks at elapsed.

> > 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.

Well, my feeling is that Posix.ProcEnv.times should correspond to the
POSIX times function -- goofy as that function might be.  I guess my
fundamental issue would be with the Basis Library, because it requires the
results to be of type Time.time, rather than as clock ticks, and it
doesn't specify how the conversion (i.e., what rounding) should be done
when converting from clock ticks to Time.time.

The other issue with using getrusage is that it will require three
successive system calls.  One with RUSAGE_SELF, one with RUSAGE_CHILDREN,
and one to get elapsed, which isn't in the rusage struct.  Maybe it's just
me, but the times function feels like it gives me a snapshot of all the
times, whereas when we make successive calls, I know that they are reading
different times.  (This bothers me with the MLton.RUsage.rusage
implementation, but I don't know of any way around it.)