Performance Analysis Tools - Project 2 - Fall 2000 | CSE 691, Study Guides, Projects, Research of Engineering

Material Type: Project; Class: Special Problems in Computer Systems Engineering; Subject: Computer Engineering; University: Syracuse University; Term: Fall 2000;

Typology: Study Guides, Projects, Research

Pre 2010

Uploaded on 08/09/2009

koofers-user-fqd
koofers-user-fqd 🇺🇸

10 documents

1 / 9

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
CSE 691 – Software Modeling and Analysis
Project #2 – Performance Analysis Tool
Aaron Gerega
10/16/00
pf3
pf4
pf5
pf8
pf9

Partial preview of the text

Download Performance Analysis Tools - Project 2 - Fall 2000 | CSE 691 and more Study Guides, Projects, Research Engineering in PDF only on Docsity!

CSE 691 – Software Modeling and Analysis

Project #2 – Performance Analysis Tool

Aaron Gerega

The goal of the performance analysis tool project is to implement a simple MFC dialog application that can be used to test the running time of executables as well as simple algorithms. Such a tool will prove valuable during the design of larger systems where timing will be a deciding factor among various approaches. Timing measurements are based on an average running time over multiple executions. In order to measure the execution time of an executable, the user simply selects the application, selects the number of times they’d like to execute the program, run the program and wait for the results to come back. In order to time simple algorithms, the user must embed the algorithm into the program and recompile. Timing results are displayed to the user interface as well as written to a log file. A final requirement is to allow the user to disable the algorithm code on the fly in order to compute the time spent performing overhead operations. Controls are provided for this in the interface but it is up to the programmer to provide the control logic for to skip the processing loop. Architecture The basic layout of the application is divided into a user interface and the behind the scenes processing. An MFC dialog application provides a perfect fit with its built in message loop and the ease with which message handlers can be added. The interface provides the user the ability to choose between timing the internal algorithm or an external application with a group of radio buttons. A second set of radio buttons provides the user the opportunity to turn the algorithm that they wish to time on or off for the purposes of measuring overhead. Edit boxes exist for the user to select an application to run, choose a file to log the results to and enter the number of iterations to be executed. Once all of the options have been selected, the user simply clicks the execute button and the timing process begins. In the case of the internal algorithm, the function is called inside of a tight loop and the total time averaged by the number of executions. If an external application is executed, the user will see the program run in a console window that disappears as soon as the application finishes execution. Again, total run time is divided by the number of iterations to compute an average running time.

The TIMER application is comprised of four distinct modules. The TIMER module provided by the MFC application wizard is responsible for driving the application. The TestProgram module defines a simple program that opens a file and searches it for the string “Visual.” This module is provided solely for testing purposes. FawcettTimer is a timing class that provides a friendly interface for computing a delta time in milliseconds between a starting and ending point. Finally, TIMERDlg provides the user interface and the underlying processing for the application. It is responsible for handling the various windows messages generated by user actions and contains methods for spawning processes and iterating over embedded functions. TIMERDlg TIMER Test Program FawcettTimer

Design Description Since the architecture chooses to use a basic windows dialog application to implement the performance analysis tool, much of the high level design is provided by the MFC wizard. Below is a graphical representation of the system with details provided where the design strays from the given wizard architecture. The MFC wizard provides the CDialog, CTIMERDlg and CTIMERApp classes. It is interesting to note that although the design uses 6 different classes, only CTIMERDlg needed to be modified for the project so this is where the discussion will focus. Briefly, the CDialog class is provided by MFC to create a dialog box. The timer class is provided by Jim Fawcett and acts as a friendly wrapper around C timing routines. The CTIMERApp class derives from CWinApp which is itself a child of CWinThread. It is within this application thread that the CTIMERDlg is created and displayed for user interaction. A quick glance over the CTIMERDlg class reveals a number of member variables and a number of methods. The member variables are broken into two categories. The first is the controls such as the CEdits and CButtons. These objects directly map to controls displayed in the dialog and are used by the application to determine what the user wants. For instance, the number of requested iterations is obtained by retrieving the string from the m_editIterations member and converting it to a number. For neatness, invalid characters are removed from the string and the display updated accordingly. The remainder of the members store internal state used by the class when it is given the command to execute. m_buttonExecutable : CButton m_buttonLog : CButton m_editExecutable : CEdit m_editIterations : CEdit m_editLog : CEdit m_editResults : CEdit m_executableName : CString m_executeAlgorithm : bool m_iterations : int m_logName : CString m_on : bool m_radioAlgorithm : CButton m_radioOn : CButton m_timer: timer CTIMERDlg(CW nd* pParent) OnInitDialog() : BOOL OnQueryDragIcon() OnSysCom mand(...) OnOK() : void OnPaint() : void OnButtonExecutable() : void OnButtonLog() : void OnRadioAlgorithm() : void OnRadioExecutable() : void OnRadioOff() : void OnRadioOn() : void ProcessResults() : void SpawnProcess() : void CTIMERDlg CDialog CWinThread CTIM ERApp CWinApp endTime : bool isRunning : clock_t startTime : clock_t timer() start() : clock_t stop() : clock_t elapsed() : clock_t timer

1 *

interface to choosing files assures that the user doesn’t try to run an executable that doesn’t exist. When the user presses enter or clicks the execute button, the OnOK message handler is invoked. The message handler takes care of retrieving the number of iterations, displaying the number of iterations that it will actually perform, performing the timing test either directly or through a method call and then finally invoking the method to process the results. An alternative to writing back the number of iterations to the iterations edit box would be to check the input at each keystroke to allow only positive integer entries. The TestProgram() method is a global method defined in the TestProgram module. The TestProgram module was also compiled for use in testing the process timing routines. Client dlg:CTIMERDlg m_editIterationsCEdit m_timer:timer dlg.OnOK()dlg.OnOK() GetW indowText()GetW indowText() iterStringiterString convert string to floatconvert string to float SetW indowText(iterations)SetW indowText(iterations) if m_executeAlgorithm start()start() TestProgram() repeat m_iterations times TestProgram() stop()stop() SpawnProcess() else SpawnProcess() ProcessResults()ProcessResults()

The OnOK message handler calls to helper methods: SpawnProcess and ProcessResults. The SpawnProcess method initializes the process parameters, starts the timer, runs and then stops the timer. The only “non-standard” options selected are the executable to run and the command line parameters to pass to the executable. The executable name is retrieved from the m_editExecutableName edit box. The command the parameter is NULL if the user selected the algorithm on mode, otherwise it is set to “norun” which is a hint for the executable to skip non- overhead code. ProcessResults is called regardless of the options chosen by the user. It is responsible for writing the results to the display as well as append the data to a designated log file. A timer::elapsed call is made to retrieve the total number of milliseconds that the execution period lasted. This data is divided by the number of iterations selected to determine the average running time of the function or executable. An ostrstream is used to format the results before they are written out to the m_editResults edit box in the dialog. The method then checks the m_editLog edit box to get the name of the log file, opens an ascii append stream and writes the formatted results to the stream. Client dlg:CTIMERDlg m_timer:timer W in32 Libraries dlg:CTIMERDlg m_timer:timer m_editResults:CEdit m_editLog dlg.SpawnProcess()dlg.SpawnProcess() Initialize Process ParametersInitialize Process Parameters start()start() Repeat m_iterations times CreateProcess()CreateProcess() stop()stop() elapsed()elapsed() timetime Compute ResultsCompute Results SetW indowText(Results)SetW indowText(Results) GetW indowTest()GetW indowTest() logfilelogfile W rite results to logfileW rite results to logfile dlg.ProcessResults()dlg.ProcessResults()