profiling

Matthew Fluet Matthew Fluet <fluet@CS.Cornell.EDU>
Wed, 23 Jan 2002 09:47:55 -0500 (EST)


> I checked in a bunch of changes to profiling that incorporates this
> code and fixes the above problem.  I made some changes to the SML side
> of the code (e.g. checking for accidental freeing of the current
> profile array), and moved even more code from the C side to the SML
> side (e.g. the itimer stuff).

Looks good.

> It passed a simple test but is mostly untested.  Please check it out
> (and feel free to fix bugs :-).

I checked in a couple of fixes to main.sml and Makefiles.

The one, major, outstanding bug is that compiling -p a program without any
references to MLton.Profile.* results in no profile information being
gathered; we're being pimped by dead-code elimination, which eliminates
all the side-effecting statements that start the profiling and install the
atExit code. In fact, you need a reference to include a reference to
MLton.Profile.{current,setCurrent}.  

I suppose we could toss such a reference into suffix.sml, but that's going
to drag in the setting of the Itimer and also some file IO stuff on every
compile.

Alternatively, we could put such a reference in another file
(profSuffix.sml), which would conditionally be appended depending on the
-p option.