[MLton-devel] MLton and profiling
Stephen Weeks
MLton@mlton.org
Mon, 10 Feb 2003 12:28:53 -0800
> > You can call "mlton -v" to find out the version number.
>
> Oops, should have tried that. Since it wasn't listed as an option when
> I typed 'mlton', I didn't think it was allowed.
Yeah. The best I could think of was to change the usage message to
-v{|0|1|2|3} version number or verbosity
It's also documented in the man page.
> I certainly prefer it the way it is now.
Sorry, I couldn't tell whether this meant you prefer 20030130 or
20030209.
> I notice that there's still only one node for the 'o' function,
> which would be confusing, but since it's the first on the list of
> ignored functions it doesn't matter at all.
Are you saying that with 20030209 you are seeing only one node for the
'o' function? That certainly wasn't the intent, and I don't see how
it could happen.
> I have only one major gripe with the source-level profiling. I write a
> lot of functions in this style:
>
> fun sort cmp =
> let
> val m = merge cmp
> fun f [] = []
> | f (xs as [_]) = xs
> | f xs = let val (l, r) = split xs (length xs div 2) in m (f l) (f r) end
> in
> f
> end;
>
> The function name as it appears in the profile is 'f', but of course
> I would prefer it to be 'sort'. Similarly, a function with no name in
> the profiling turns out to be the anonymous function in
>
> fun obj_order ({literal_order = false, ...} : parameters) _ _ c = c
> | obj_order {literal_order = true, tracking, ...} x ys c =
> foldl (fn (y,c) => if x = y then c else tm_order tracking x y c) c ys;
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> It would be a lot more helpful to list this as 'obj_order'. There are
> so many occurrences like this that it's easy to get lost looking at a
> call graph. Function 'f' calls function 'h' calls function 'f' etc.
> They all have line numbers so in principle I could go and look at the
> source, but in practice it seems too much work for non-bottleneck
> areas.
>
> I guess I'm asking to print the name of the top-level function
> surrounding the source line in question. If you think this might be
> potentially confusing, then perhaps there could be an option that
> would have the existing behaviour as default?
How about the following approach, which is both more precise than what
you request, and hopefully not too noisy.
Keep track of the lexical nesting of function names, and print inner
names as a sequence of function names separated by "."s. For example,
your f above would appear as sort.f, and your anonymous function would
appear as obj_order.<anon> (and of course the source position would
still be there if you want it).
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel