• Project title:

    Stopwatches for Program Timing
    (DRAFT - work in progress - elaboration is not finished - 9/25/00)

  • Sponsor: Delsoft.com

  • Goals: Make a program timing and timings report facility which supports good display of timing results both concurrently with the run being timed and as a "postmortem" activity.

  • Rationale:     Cost: we should be able to make a much more useful timing facility than currently exists (even the nice stopwatch metaphor facility) in the course of a semester.
        benefit: In some xoftware projects runtime performance of the system or critical parts of it is of critical importance. This system will facilitate the measurement, observation, and ultimate reporting of performance. It will be designed with academic/research algorithm designers in mind, but may be useful in a number of other contexts such as managing the use of benchmark suites for hardware and software system performance measurement. Additionally, we hope the example will provide some useful illustration of software design methodology in CISC 475, fall 2000. Cost: Coding effort. No new hardware or software is expected to be needed to support the project. Maintenance costs could be considerable if the system is accepted. We will try to design cleanly and encourage others to handle enhancements to minimize such costs. No ongoing technical support is anticipated to be necessary.

  • Scope: Elaboration has taken at least a person-day and is expected to take another, for a project estimated to require no more than 2 person/months for design refinement and implementation.

    System Requirements Agreement

  • Glossary of terms:
    A stopwatch : An object which can be called to record identified measurements in a database. Note: We have stopped using the term "timer" for this concept to avoid confusion with alarms and count down timers and the like.

    A database of measurements: An object suite which serves to record measurements from one or more runs of one or more programs but presumably restricted to one project. It should be queryable in reasonable ways to support timing reports and concurrent (with a timed run) display of measurements.

    A clock : A low-level clock, an object which returns measurements of some concept of time. It is required that successive readings of the clock will reflect nondecreasing values of the "time" measured. If we wish to discuss displays that look like familiar physical clocks we will disambiguate by referring to "display clocks" or "high level clocks" or "gui clocks". For this project, a no-adjective "clock" is a low level clock.

    Time : Any function guaranteed to be nondecreasing during the course of a program run. We expect that we will be able to design the system without any more assumption than that, though we expect the user will interpret the data using beliefs about the clocks used that go beyond our assumption. In particular we make no assumptions about the behaviour of "real" time clocks on different processors or as read by different processes on the same processor.

  • System Functions:
    • R1. Record timing measurements from a timed program run in the database. Record processor speed and other hardare platform properties with a view to cross platform comparison.
    • R2 Display measurements taken with one or more stopwatches during the course of a run.
    • R3 Display combined measurements taken over several runs.
    • R4 Process user control of display characteristics
    • R5 Handle database management functions such as
      1. the removal of certain runs
      2. the removal of certain classes of measurement
      3. merging of two databases
      We have not decided yet if we will use an existing full featured database system or will use a custom (and very simple) database. If the latter, the database management will likely be left for the user to do with standard editiing tools (vi or emacs).


  • System Attributes:
    • A1. Minimal interference of stopwatch calls on the duration of the timed portions.
    • A2. Portability to all major hardware platforms, all major operating systems, many programming languages is a key design goal. However success specifically for C, C++, and Java programs on Solaris on Sun hardware makes it immediately useful at UDel.
    • A3. Simplicity and Clarity of the design is a goal since we want to encourage maintenance and extension by others.
    • A4. Simple user interface. We'll try to follow Kernigan's dictum: "Simple things should be easy, difficult things should be possible."
    • A5. Usefulness as a classroom example for CISC 475, Fall 2000.


  • Use Cases:
    • UC1. Time a program
    • UC2. postmortem report
    • UC3. live report


  • Risks analysis:
    • Requirements risks:
      • The stopwatch idea itself is very clear.
      • However, there is a great variety in the reasons people measure program performance. We'll address this issue by making the display/report tool very simple and clear (so as to be useful to some and not a big time sink to overcome for those who need something else). Secondly we'll make the database very simple in structure so that it will be easily used for other kinds of display/report extensions.
    • Technological risks:
      • We don't have ready access to many platform/opsys environments for testing (esp various Windows and Mac versions, for instance). For this reason we'll limit our portability efforts at first to what follows directly from use of Java.
      • We plan to use C++ and Java primarily. The former is well established and rather stable. Java is a moving target. We'll be cautious about this, but we work with Java in the hopes that it will be a good way to provide portability in our environment of limited time-for/access-to the myriad platforms.
    • Skills risks:
      • We have limited Java experience. Will have to allow for the learning curve.
      • If we interface to a full featured database system such as oracle we will also have a learning curve on that.
    • Political risks:
      • Good news: We are the darling project of the big cheeze.
      • Bad news: Since the big cheeze has strong opinions about it, we'll have to cater to his whims on the design.
      • Good news: We have the most experienced programmers in the company.
      • Bad news: We have the smallest team with the least available time
      • Good news: Since we are running as an example we can use some class preparation time for project development.
      • Cautionary news: We must work to keep this project interesting and relevant as the class works on their projects.
  • System Attribute driven design decisions:
    • Use Java for display/report system.
    • Have both C++ and Java Stopwatches. C++ for performance in application to C++ programs.
    • Database: Custom build simple database or use Oracle or use ...
    • Display/report metaphor: initially the basic will be a (potentially long) bar graph, a scroll of labeled horizontal bars color coded to the stopwatches. May use the analog clock face and/or pie chart metaphors also.