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.