[MLton-devel] New release of MLton: call-graphs

[Stephen Weeks]

> > A -> B -> C
> > A -> C
> >
> > Suppose we call -graph '(not B)'.  Then, should there be a solid edge
> > from A to C, a dotted edge from A to C, or both?  According to the
> > definition I gave above, the answer is both.
> 
> In my opinion only a solid line should be displayed, since it's "more
> important".

OK.  So how's this for a definition:

	-graph <exp> evaluates <exp> to a set of nodes S as before.
	There is a dotted edge from A to B iff 
	1. A and B are in S, and
	2. There is a path from A to B of length >1 going only through
		nodes not in S, and
	3. There is no path from A to B going only through nodes in S

It's not any more difficult to implement, but I think it could be
confusing to people who might expect to see a dotted line to represent
the missing path.  I think it could be particularly misleading when
looking at stack percentages.  Anyways, I'll think about it some more
(input appreciated) and will implement something along these lines.

> Also, a problem with the dotted lines is that they may appear
> spuriously, because of the interaction with higher-order functions
> (as in the example I found, copied below).

Agreed -- this is the same problem fixed by -profile-split.

> Perhaps a good solution to this is for mlton to assume
> -profile-split '.*', and use mlprof to combine the profiling
> information for different instances of each function that satisfies
> the -graph predicate. [I guess what I'm asking for here is for the
> -profile-split argument to be moved from mlton to mlprof.]

It is clearly subjective, but from the point of view of user
understanding I believe that the default of not splitting is the right
thing.  Because the splitting is heavily implementation dependent, it
can be confusing for users to see many duplicates of a function.  I
think it will be easier for users to make a positive list of the
functions that should split (General.o, ...) than to make a list of
the functions that should not be split.

I do agree that it would be nice to move -profile-split from mlton to
mlprof to avoid having to recompile.  You seem to be suggessting an
implementation technique for doing so -- namely, to split everything
and then to combine with mlprof.  Unfortunately, this doesn't quite
work.  If you build in -profile-split '.*' to mlton, then it is
impossible with -profile-stack true to combine the stack % of two
different instances of a function f.  Why?  Because the stack % of
each instance measures the number of ticks where that instance is on
the stack.  To combine them, we would have to know the number of ticks
where either instance is on the stack, which would require knowing for
each tick whether one or both was on the stack.

The only approach I can think of to move -profile-split would be to
keep one bit of profiling data for each function and another bit for
all of its instances.  Then, depending on whether the function is
split, mlprof can do the right thing.  That increases the amount of
profiling data and work done by the profiler, but not too much.  I'll
look into it.




-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel