Skip to content

Commit 807bc16

Browse files
committed
Latex Report
1 parent 6ddb7bb commit 807bc16

File tree

7 files changed

+842
-0
lines changed

7 files changed

+842
-0
lines changed

doc/PdfLatex/1.png

141 KB
Loading

doc/PdfLatex/2.png

198 KB
Loading

doc/PdfLatex/Finalreport.aux

Lines changed: 20 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,20 @@
1+
\relax
2+
\select@language{english}
3+
\@writefile{toc}{\select@language{english}}
4+
\@writefile{lof}{\select@language{english}}
5+
\@writefile{lot}{\select@language{english}}
6+
\@writefile{toc}{\contentsline {section}{\numberline {1}Introduction}{1}}
7+
\@writefile{toc}{\contentsline {section}{\numberline {2}Approach}{1}}
8+
\@writefile{toc}{\contentsline {section}{\numberline {3}Instrument Code}{2}}
9+
\@writefile{toc}{\contentsline {section}{\numberline {4}Collect Run Time Information}{2}}
10+
\@writefile{toc}{\contentsline {section}{\numberline {5}Post Process}{2}}
11+
\@writefile{toc}{\contentsline {section}{\numberline {6}System Design}{3}}
12+
\@writefile{toc}{\contentsline {subsection}{\numberline {6.1}Proxy Server}{3}}
13+
\@writefile{toc}{\contentsline {subsection}{\numberline {6.2}Web Interface}{4}}
14+
\@writefile{toc}{\contentsline {subsection}{\numberline {6.3}Testing}{4}}
15+
\@writefile{toc}{\contentsline {section}{\numberline {7}Results}{4}}
16+
\@writefile{toc}{\contentsline {section}{\numberline {8}References}{4}}
17+
\@writefile{lof}{\contentsline {figure}{\numberline {7.1}{\ignorespaces Top Down View}}{5}}
18+
\newlabel{overflow}{{7.1}{5}}
19+
\@writefile{lof}{\contentsline {figure}{\numberline {7.2}{\ignorespaces Bottom Up View}}{5}}
20+
\newlabel{overflow}{{7.2}{5}}

doc/PdfLatex/Finalreport.log

Lines changed: 606 additions & 0 deletions
Large diffs are not rendered by default.

doc/PdfLatex/Finalreport.pdf

396 KB
Binary file not shown.
24.9 KB
Binary file not shown.

doc/PdfLatex/Finalreport.tex

Lines changed: 216 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,216 @@
1+
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
2+
% Short Sectioned Assignment
3+
% LaTeX Template
4+
% Version 1.0 (5/5/12)
5+
%
6+
% This template has been downloaded from:
7+
% http://www.LaTeXTemplates.com
8+
%
9+
% Original author:
10+
% Frits Wenneker (http://www.howtotex.com)
11+
%
12+
% License:
13+
% CC BY-NC-SA 3.0 (http://creativecommons.org/licenses/by-nc-sa/3.0/)
14+
%
15+
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
16+
17+
%----------------------------------------------------------------------------------------
18+
% PACKAGES AND OTHER DOCUMENT CONFIGURATIONS
19+
%----------------------------------------------------------------------------------------
20+
21+
\documentclass[paper=a4, fontsize=11pt]{scrartcl} % A4 paper and 11pt font size
22+
23+
\usepackage[T1]{fontenc} % Use 8-bit encoding that has 256 glyphs
24+
\usepackage{fourier} % Use the Adobe Utopia font for the document - comment this line to return to the LaTeX default
25+
\usepackage[english]{babel} % English language/hyphenation
26+
\usepackage{amsmath,amsfonts,amsthm} % Math packages
27+
28+
\usepackage{lipsum} % Used for inserting dummy 'Lorem ipsum' text into the template
29+
30+
\usepackage{sectsty} % Allows customizing section commands
31+
\allsectionsfont{\centering \normalfont\scshape} % Make all sections centered, the default font and small caps
32+
33+
\usepackage{fancyhdr} % Custom headers and footers
34+
\pagestyle{fancyplain} % Makes all pages in the document conform to the custom headers and footers
35+
\fancyhead{} % No page header - if you want one, create it in the same way as the footers below
36+
\fancyfoot[L]{} % Empty left footer
37+
\fancyfoot[C]{} % Empty center footer
38+
\fancyfoot[R]{\thepage} % Page numbering for right footer
39+
\renewcommand{\headrulewidth}{0pt} % Remove header underlines
40+
\renewcommand{\footrulewidth}{0pt} % Remove footer underlines
41+
\setlength{\headheight}{13.6pt} % Customize the height of the header
42+
43+
\numberwithin{equation}{section} % Number equations within sections (i.e. 1.1, 1.2, 2.1, 2.2 instead of 1, 2, 3, 4)
44+
\numberwithin{figure}{section} % Number figures within sections (i.e. 1.1, 1.2, 2.1, 2.2 instead of 1, 2, 3, 4)
45+
\numberwithin{table}{section} % Number tables within sections (i.e. 1.1, 1.2, 2.1, 2.2 instead of 1, 2, 3, 4)
46+
47+
\setlength\parindent{0pt} % Removes all indentation from paragraphs - comment this line for an assignment with lots of text
48+
\usepackage{graphicx}
49+
50+
%----------------------------------------------------------------------------------------
51+
% TITLE SECTION
52+
%----------------------------------------------------------------------------------------
53+
54+
\newcommand{\horrule}[1]{\rule{\linewidth}{#1}} % Create horizontal rule command with 1 argument of height
55+
56+
\title{
57+
\normalfont \normalsize
58+
\textsc{University of Massachusetts Amherst- Computer Science-Fall 2013} \\ [25pt] % Your university, school and/or department name(s)
59+
\horrule{0.5pt} \\[0.4cm] % Thin top horizontal rule
60+
\huge JSProf: A Javascript Profiler \\ % The assignment title
61+
\horrule{2pt} \\[0.5cm] % Thick bottom horizontal rule
62+
}
63+
64+
\author{Authors: Eswer Kishore Kumar, Nimish Gupta} % Your name
65+
66+
\date{October 21,2013} % Today's date or a custom date
67+
68+
\begin{document}
69+
70+
\maketitle % Print the title
71+
72+
%----------------------------------------------------------------------------------------
73+
% PROBLEM 1
74+
%----------------------------------------------------------------------------------------
75+
76+
\section{Introduction}
77+
78+
The aim of this project is to build a Javascript profiler written in Javascript. It is supposed to be browser independent. The profiler is expected to report the following information
79+
80+
%------------------------------------------------
81+
82+
\begin{enumerate}
83+
\item Execution times for individual functions
84+
\item Edges between caller and callee functions
85+
\item Frequency of calls
86+
\item Reconstruction of the dynamic call paths
87+
\item Identification of hot paths
88+
\item Tracking sources/causes of asynchronous callbacks
89+
\end{enumerate}
90+
91+
%----------------------------------------------------------------------------------------
92+
Original problem statement can be found at: http://plasma.cs.umass.edu/emery/grad-systems-project-1
93+
94+
%------------------------------------------------
95+
96+
\section{Approach}
97+
The basic flow of our application is like this. Individual stages are discussed in detail later.
98+
99+
Instrument code --> Collect Run Time data --> Post Process --> Show Results
100+
101+
\section{Instrument Code}
102+
To collect the required information we need to have our special instructions in specific places in code. To collect and show the above information we need to track each function entry and function exit. For tracking asynchronous callbacks we need to look for call expressions in Javascript code. To capture function declarations and expressions in Javascript we first represent it into an annotated canonical form using a Javascript parser. We then traverse the canonical form to look for function declarations and function expressions and add our code to all functions found upon traversal. We use Esprima (http://esprima.org/) parser and Escodegen (https://github.com/Constellation/escodegen) to accomplish parsing and rewriting respectively.
103+
104+
Since a function can have multiple exit points, we wrap the function code into try finally block to ensure that we successfully capture function exit event.
105+
106+
Ex : Before instrumentation
107+
108+
function ()
109+
110+
{
111+
112+
<body>
113+
114+
}
115+
116+
After instrumentation
117+
118+
function ()
119+
120+
{
121+
capturefunctionentry ();
122+
123+
}
124+
125+
try
126+
127+
{
128+
129+
<try block>
130+
131+
}
132+
133+
finally
134+
135+
{
136+
137+
capturefunctionexit ();
138+
139+
}
140+
141+
142+
\section{Collect Run Time Information}
143+
144+
At run-time, the actual code interacts with our code that captures the run time call stack information. Since we are interested in capturing the time of function execution it is imperative that the overhead of our instrumentation code be minimal. We have taken various measures to ensure that this is the case. We collect call function call information on an array and tag it with start and stop time. The call stack information gives us edges between callers and callees, the time of execution of the edge and the number of times the call was made. As the program executes this data if not processed could easily occupy a lot of memory over a small interval of time. A program consists of fixed functions that are called arbitrary number of times. So reducing the callstack into edge information helps keep the memory overhead low. Since this will incur overhead if done in real-time so with do it asynchronously at a later stage. We rely on the fact that Javascript programs are mostly asynchronous to keep our memory footprint low.
145+
146+
\section{Post Process}
147+
148+
All the data we have collected, needs to be passed to be processed for results. Our post processor takes the collection of edges as inputs and forms a graph out of it, propagating the times from edges to nodes.
149+
We have taken care of self-recursion. The resulting data structure has the following information
150+
151+
For every function in graph we have the following information.
152+
153+
\begin{enumerate}
154+
\item Its caller functions (parents)
155+
\item Children
156+
\item Total time in ms
157+
\item Self time in ms
158+
\item Number of calls made to this function
159+
\item Number of self recursive calls made
160+
\end{enumerate}
161+
162+
The data is presented in a tree-tabular format. We present two views to the user.
163+
164+
\begin{enumerate}
165+
\item Top Down View
166+
\item Bottom Up View
167+
\end{enumerate}
168+
169+
Top Down View: Top down view traces the execution flow of program, starting from the Javascript Engine context. The hot-path is highlighted with a distinct color. Initially the whole tree-table is collapsed to one single node. When expanded, it shows the functions which were called from the clicked function. The functions can be further clicked to know their children until we encounter a leaf node.
170+
171+
Bottom Up View: Bottom up view shows the list of functions along with their individual statistics. The functions comprising the hot-path are again highlighted. Upon clicking a function the tree expands to show the functions that calls the function that was clicked. This can be traced until we encounter the JS Engine context.
172+
173+
We have used a third party library called JQuery and JQuery tree-table to help us with the display of collapsible tree-table.
174+
175+
\section{System Design}
176+
\subsection{Proxy Server}
177+
A web page can have embedded JS and link to script files. We want the instrumentation to be transparent to the user. We have written a proxy program in node js that intercepts http requests. Instruments JS files before we send it to user. It also embeds link to our modules that collects and process the run-time data. This is done in the <head> tag to make sure that the modules are available before any JS code starts executing on the web page
178+
179+
\subsection{Web Interface}
180+
We ask the user to enter the URL which he would like to profile, make the request to the web-page (through proxy server). We use an Iframe based UI to open the source page for user to interact with it. On top of the page we have a button that shows the user the result of execution. Since the pages are cross domain. We use message passing to communicate with our embedded module in the Iframe to pass the requests and profiling data for post processing.
181+
182+
\subsection{Testing}
183+
Almost all the modules have been developed in node js compatible JS, but they don't use any node specific feature. Since proxy is server side thing we have used written it entirely in node. Additionally we are using the browserify (http://browserify.org/) module of node to convert the node modules to browser side JS. We have tested the individual modules in node using the few benchmarks (http://benchmarksgame.alioth.debian.org). Browser side testing was done with Chrome and Firefox.
184+
185+
\section{Results}
186+
We are able to collect the required information and show it except that we are currently not tracing asynchronous callbacks. There is a slight overhead incurred while running the instrumented programs. We have been using http://esprima.org/demo/functiontrace.html as our reference and we have generally observed that the overhead involved is ~15-20%. The memory overhead is slightly high as we would have liked it to be. Some snapshots of results are given below
187+
188+
\begin{figure}[ht!]
189+
\centering
190+
\includegraphics[width=150mm]{1.png}
191+
\caption{Top Down View}
192+
\label{overflow}
193+
\end{figure}
194+
195+
\begin{figure}[ht!]
196+
\centering
197+
\includegraphics[width=150mm]{2.png}
198+
\caption{Bottom Up View}
199+
\label{overflow}
200+
\end{figure}
201+
202+
\section{References}
203+
204+
\begin{enumerate}
205+
\item Esprima JS Parser (http://esprima.org/)
206+
\item Escodegen (https://github.com/Constellation/escodegen)
207+
\item Jquery (http://jquery.com/)
208+
\item Jquery tree-table (http://plugins.jquery.com/treetable/)
209+
\item Node (http://nodejs.org/)
210+
\item Browserify (http://browserify.org/)
211+
\item Test Benchmarks ( http://benchmarksgame.alioth.debian.org)
212+
\item Esprima function trace ( http://esprima.org/demo/functiontrace.html)
213+
\end{enumerate}
214+
215+
216+
\end{document}

0 commit comments

Comments
 (0)