[MLton-devel] experimental release of source-level profiling

Matthew Fluet fluet@CS.Cornell.EDU
Fri, 17 Jan 2003 13:34:01 -0500 (EST)

> > When investigating something, I'm tempted to put in a bunch of eta
> > expansions for let bindings:
> ...
> > in order to get more information.  It seems that we could provide compiler
> > support for that, although I understand that tracing through every let
> > binding in the program would be too expensive.
> Actually maybe not.  For time profiling, it's just some more labels
> that get emitted.  And for allocation profiling, it's some more C
> calls, but probably not too many more.

That may be true.  I was just thinking that there probably an order of
magnitude more val bindings than there are function bindings.

> > Perhaps we could support some comment pragmas for enabling and
> > disabling profiling of bindings.
> I don't see why that's better than explicit thunking.

I'd argue that it's easier and less intrusive in the code.  Particularly
for very large functions with lots of bindings, I'd think it be easier to
just do
(*#profile-bind on*)
(*#profile-bind off*)
than it would be to modify all the bindings.  Also, it doesn't obfuscate
the code just for profiling support.  And, the compiler support I was
thinking of was to wrap bindings in Enter/Leave statements automatically,
without needing to explicitly thunk.

This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your 
clients even if they use browsers that are limited to 40 bit encryption. 
Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
MLton-devel mailing list