Profiling Actions

Overview

The goal of this project is to add the concept of actions to the Eiffel Studio profiler to make the timing of GUI applications easier.

action_timer.start_action ("myAction")

-- action to time

action_timer.stop_action

around interesting parts of code.

The tool checks if the directory already contains a file named myAction.br (base run). If it does a file named myAction.cr (comparison run) is created, otherwise the base run file is created.
Then the user can view the timed actions (requires base and comparison runs exist) to see if his code modifications slowed down or speeded up the code

I modified the files eif_option.h and option.c in the run-time. When an action ends I save the profiling information into a file with the name of the action. After that the profiling stack is freed and reinitialized:

ht_free(class_table);
prof_stack_free();
initprf();

For this to work stop_profile has been modified to check a flag and not report a profile stack corruption if the flag is true.
- Using a more fine-grained resetting might have been nicer but all my attempts in this direction resulted in an unlocalized division by zero error somewhere in the C code.

When the Action Timer is invoked it checks the given directory for .br and .cr files and if both are present with the same name the action is added to the list.
- The files are parsed using a subclass of PROFILE_CONVERTER which overrides a feature so the converted information isn't written to disk.
A new class inheriting from PROFILE_INFORMATION has been added to make total execution time always available.
The actions are then displayed with a comparison of the execution times and with detailed profiling information.

It's not possible to have nested actions. This would require larger changes to the run-time.
It's not possible to profile the whole application and specific actions at the same time.
- This would require keeping separate records for the actions.
- Such a change would also allow nested actions, however.