Designer runs program containing stopwatch calls. At the construction time of the first stopwatch Designer is offered opportunity to record a log entry for the run. This entry is meant to indicate the point of this measurement, how the code differs from a previous run, etc. I.e. the log entry should be helpful in interpreting the measurements at a later date. Then one or more timers are started and stopped, possibly repeatedly and possibly with intermediate "lap" times recorded. The individual measurements are buffered and sent to a database at appropriate intervals and with attention to minimal disturbance of time measurements. Net result: Database is augmented with

1. A record of the program and it's version, the date and time of the run. In the absence of access to the version control system being used, the date and time will serve as the version. If possible this record should also contain information on the machine in use including it's speed and memory and conceivably one or more usage (load factor) measurements.
2. A record of each measurement taken, including id of the type of time it measures, and a string identifying the measurement that is supplied with the call to the stopwatch. Design remark. We need to decide if the measurement will include the time from the previous measurement on the same clock or the time from start or both. ...probably the time from start to be true to the stopwatch metaphor.

1. Code is compiled with a dummy suite of stopwatches. An optomizing compiler will remove even the function calls to the dummy stopwatches so that the run will be a "production" run with no penalty for containing the stopwatch calls. The designer will not be asked for a log entry and no interaction with the database will occur.