Outline of Class 32: Profilers, Revisited

Miscellaneous

• I'm working hard on my book chapter, and will get back to grading when it's finished. I'm hoping to have most things graded by next Monday. Thanks for your patience.
• On Wednesday, we'll talk about regular expressions.
• On Friday, we'll talk about associative arrays.

Profilers, Continued

• In an earlier class, we talked about general issues in profiling.
• Today, we'll look at how one might profile programs by hand and/or write their own profilers.

Hand-Profiling

• It the profiler available for your language or environment is inappropriate, you may choose to hand profile your program.
• That is, you will insert commands to keep track of the number of times particular lines are executed and the total amount of time spent executing each line.
• E.g., you'll turn
  line-of-code;
  into something like:
++counter-for-this-line;
before = System.currentTimeMillis();
line-of-code;
after = System.currentTimeMillis();
time-for-this-line += after-before;
• A more object-oriented (but perhaps less precise) solution would be to develop a Profiler class and build a Profiler object for each line you want to profile.
• The interface to such a class might look like
  • Profiler() -- create new profiler.
  • Profiler(String rep) -- create a new profiler with the textual representation of the line of code you're profiling.
  • pre() -- Call immediately before the execution of a line you're profiling.
  • post() -- Call immediately after the execution of a line you're profiling.
  • int count() -- Get the number of times the line is executed.
  • int time() -- Get the total amount of time spent executing that line (plus, perhaps, the extra from these methods).
  • String report() -- Give a simple report of the time spent.
• We'd use it in a similar way to the lines we inserted above:
profiler-for-this-line.pre();
line-of-code; profiler-for-this-line.post();
• If we choose not to create one profiler per line, we might instead do
profiler-for-this.class.pre(info-on-this-line);
line-of-code;
profiler-for-this.class.post(info-on-this-line);
• Implementation of the line-based Profiler class is also relatively straightforward; implementation of the paremter-based one may be harder.

Rolling Your Own

• While hand-profiling is useful for small pieces of code, it is painful at best for larger pieces. Inserting and removing profiling information is something that should be automated.
• If the language you use doesn't provide its own profiler, or its profiler is inappropriate, you can always create your own.
• How? By writing a program that automatically fills in pieces of code like I've given above.
• That is, your profiler program needs to
  • Create a modified version of the original program that contains extra statements.
  • Use those extra statements to gather information about the program.
  • Gather information based on those extra statements.
  • Present the information to the user.
• What should these special statements look like? If we're going to want to post-process information about the program, we may want to write information to a file.
  • Each time a profiled line is executed, we write information about that line to the file (timing).
  • We'll need to open that file at the beginning of the program.
  • We'll need to close that file at the end of the program.
• This is harder, but still possible, in a modular language like Java. Why? Because we'll need to worry about profiling multiple classes, which may mean updating not just one file but many, and having the changes interrelate.
• Some decisions:
  • Where do we want to put the modified version of the original program?
    • In the same directory, but with a different name (complicates uses of the modified version).
    • In a new directory, but with a new name (complicates use of CLASSPATH).
    • ...
  • Where does the profiling output go?
    • One file per "program"?
    • One file per class?
    • One file per "line"?
    • ...
  • What do we put into the profiling output?
    • Start and stop for each thing profiled?
    • Just difference in times for each thing profiled?
    • ...
  • How do we present the results of profiling?
    • In summary form?
    • With a modified version of the original program?
    • ...
  • How do we choose which lines or methods to profile?
    • Do everything.
    • Allow a "PROFILE" comment on lines that admit profiling.
    • ...
  • Do we create separate profiler objects or just use it as a static class?
  • How do we deal with exceptions?
  • ...
• Many, but not all, of these decisions can be hidden within our Profiler class.
• What are the changes our profile inserter has to make?
  • Insert an import Profiler statement at the appropriate point.
  • If we're creating separate profilers for each class, we'll need to add a static variable to the class and initialize that variable. Name choice is important!
  • If we're creating separate profilers for each object, we'll need to add a field to the class and initialze that field in each constructor (since constructors may call each other, this requires some care).
  • Insert profiling commands around each line. Since this can affect operations like for loops, we'll need to worry about blocking the commands with braces, as in
    { prof.pre(info); command; prof.post(info); }

Tracing

• An operation related to but not quite the same as profiling is tracing.
• In tracing, you list the steps your program goes through as it executes.
• This can be helpful in seeing whether the flow of control is that which you expected.
• It can also be helpful in traking down pieces of code that are called multiple times.
• Java provides a simple Java virtual machine tracer using java -t. Warning! This produces huge trace files.
• For less granular tracing, you may need to insert your own tracing commands (either manually or automatically).