Project 1 - JSProf
Due October 18, 2013
Your profiler should report the following information:
- execution times for individual functions
- edges between caller and callee functions
- frequency of calls
- reconstruction of the dynamic call paths
- identification of hot paths
- tracking sources/causes of asynchronous callbacks
You will need to write a profiling program that translates the target program into an instrumented program. There are several approaches you can take. One way is to define an instrumented function object that behaves exactly as the default function, but tracks the desired information. Another way is to interleave data collection calls throughout the code.
Some parsers to consider are the following (we recommend the first two):
Be careful that your rewriting only affects the instrumented program, and not any code introduced by your profiler. Other potential pitfalls include:
- planned timing (setInterval)
- in callback-heavy applications, there is the potential for arbitrarily deep calls
- interference between the profiler’s added code and the actual program code.
You will need to provide a test suite with your submission. You may use tests from other sources, such as http://benchmarksgame.alioth.debian.org/, but you must cite them. Your test suite must be extensible, since we will be running our own tests against your code.
You will be using github to manage your project. When you are ready to submit your code, tag your code with the tag name ‘final’.
Your submission should contain a Readme that explains how to run your program, how to run the test suite, and what dependencies are required. You should also include a more detailed explanation of your approach, system design, and results in a LaTeX file that can be compiled with pdflatex.Discussion / honesty policy:
You may, as a class, discuss all details of this assignment -- and I encourage you to do so via the mail alias. However, no code can be shared across teams. All assignments will be checked with plagiarism detection software. Submission of your project constitutes acceptance of the University Honesty Policy. More details below.
All projects in this course are to be done by you / your group. Violation will result in a zero on the project in question and initiation of the formal procedures of the University. We use an automated program and manual checks to correlate projects with each other and with prior solutions. At the same time, we encourage students to help each other learn the course material. As in most courses, there is a boundary separating these two situations. You may give or receive help on any of the concepts covered in lecture or discussion and on the specifics of programming language syntax.
You are allowed to consult with other students in the current class to help you understand the project specification (i.e. the problem definition). However, you may not collaborate in any way when constructing your solution: the solution to the project must be generated by you or your group working alone. You are not allowed to work out the programming details of the problems with anyone or to collaborate to the extent that your programs are identifiably similar. You are not allowed to look at or in any way derive advantage from the existence of project specifications or solutions prepared elsewhere.
If you have any questions as to what constitutes unacceptable collaboration, please talk to the instructor right away. You are expected to exercise reasonable precautions in protecting your own work. Don't let other students borrow your account or computer, don't leave your program in a publicly accessible directory, and take care when discarding printouts.
For your reference, here is the University Academic Honesty Policy.