Dolphin Profiling Support

There are a number of ways of measuring the performance and analysing the behaviour of code using existing facilities supplied with Dolphin. These techniques would be used separately to the profiling and tracing tools of Svengali.

Measuring the time required to evaluate some code is important to know where you are, and also to gauge any improvements in performance after a modification. It is very easy to spend excessive amounts of time on improving the overall time by an insignificant amount. Optimisations often arise in conflict to the readability of your code, it is important to balance this out. It is wise to keep a record of what you have modified and its actual affect if you are involved in a serious stint of profiling work.

The Time class contains two class methods for measuring the time required to evaluate a block, #millisecondsToRun: and #microsecondsToRun:. It is important to remember that Dolphin runs on top of a complicated multi tasking OS which has to respond to a large number of requests for the machines resources. To improve the consistency of results Dolphin should be the only application open, and your machine should not be connected to a network. On the other hand a more practical approach is to ensure that no other significant processing is occurring and average the results from a number of runs. One thing to watch for is that the millisecond clock appears to have a resolution of 10ms.

You can also keep track of the number of instances generated during an execution by using the #allInstances and #allSubinstances methods of Behavior. These will give results for the entire system, so you may wish to record the systems instance signature before you start an execution then report back the difference. Note that the current implementations of these methods perform a garbage collection before collecting the instances, this will consume time but may also modify the behaviour of your software, check out MemoryManager>>garbageCollect.

To get some more ad hoc feedback of what your software is actually doing during in its more self consuming moments there are the classic techniques of writing a suitable message to the Transcript indicating current location and action, counting iterations using a global or sounding the system bell (Sound bell).

The Debugger can also be used to highlight execution paths on a micro scale by stepping through the code, or by using its Animate facility which will automatically step through the whole execution. The animation facility can often slap you in the face by allowing you into the 'secret' world and forcing you to become aware of the grand amount of unexpected code that gets executed.