3.4 Profiling: the Profile structure

3.4.1 Code items

The profiler produces execution profiles for all code items. A code item is an individual piece of machine code generated by the compiler, so is the atomic unit of code as far as the interactive MLWorks environment is concerned. We shall for convenience's sake talk about profiling functions or function calls, but it is worth looking into code items to understand the profiler better.

A code item most closely corresponds to an instance of a lambda function (a fn) in the source. So in:

val f = fn x => x + 10;

The fn x => x+10 code item is profilable: an application of f to an integer value could be profiled, though in practice its execution would probably be completed so quickly that the profiler would not have time to record anything about the application.

Consider the functions foo and bar:

fun foo x = x + 10;
val bar = foo;

In calls to foo and bar, the function foo would be profiled (it has an implicit lambda) but bar would not be profiled separately from foo because it shares a code item with it.

fun frob x y = x + y + 10;
val bar = frob;
val baz = frob 3;
val qux = baz;

In the functions defined above, there are two code items for frob, one which is invoked when frob is applied to one argument, and one which is invoked when the result is further applied to another argument: frob has two implicit lambdas. These will appear separately in a profile. The functions bar, baz and qux are really just identifiers, not new code items, so will not show up separately in the profiler.

The compiler might discard code items by inlining them at their call sites. It might also generate new code items when optimizing function-calling sequences. For instance, a third code item may be generated for the function frob above, which is used when frob is called with two known arguments in machine registers.

Every code item has a name. Code items from regular functions inherit the function name. Code items from explicit lambdas (as in the first example above), are called <anon>. Code items from curried functions (like frob) have argument 1 and argument 2 appended to their names. Code items generated when optimizing have text such as <Entry> appended to their names.