Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Compare: GSoC 2012 Ruboto Performance and Tooling Mid_term_report

Showing with 28 additions and 4 deletions.
  1. +28 −4 GSoC-2012-Ruboto-Performance-and-Tooling-Mid_term_report.md
View
32 GSoC-2012-Ruboto-Performance-and-Tooling-Mid_term_report.md
@@ -1,17 +1,41 @@
**GSOC MID - TERM REPORT**
+<p align="justify">
+
This is a brief summary report of my work for the Google Summer of Code 2012 project Ruboto Performance and Tooling. The report covers the works up until the mid-term evaluation (July 8). This GSoC project aims at improving Ruboto startup time, improving user interface of Ruboto IRB and looking possibilities for AOT compilation.
+</p>
**Week 1-2**
-During this time I got familiarized with my project. I understood the ruboto code and learned the involved languages like Ruby, Jruby. I also understood the various Ruboto based projects like Ruboto Startup timer. Being new to Github, I made myself comfortable with Github environment. Having a better understanding of my project till then I re-planned my project in a more proper and scheduled manner.
+<p align="justify">
+During this time I got familiarized with my project. I understood the ruboto code and learned the involved languages like Ruby, Jruby. I also understood the various Ruboto based projects like Ruboto Startup timer. Being new to Github, I made myself comfortable with Github environment. Having a better understanding of my project till then I re-planned my project in a more proper and scheduled manner.
+</p>
**Week 3-4**
-I started working by measuring current startup time of Ruboto using apps like Ruboto Startup timer and Ruboto Startup server. I modified the Ruboto Startup Server to accept extra benchmarks and renamed the application as Ruboto Benchmark Client, and then put my hands over Ruboto Startup timer to generate multiple benchmarks other then startup time. I selected some core benchmarks and added it to Ruboto Startup timer. Some of the benchmarks are loading _YAML, loading Active Record,_ loading _Active_Support/Dependencies_. These entries will be used for later references and comparison. I contacted some other GSoC Projects and tried to know what benchmarks are they using and they will help as soon as they have something on it.
+<p align="justify">
+I started working by measuring current startup time of Ruboto using apps like Ruboto Startup timer and Ruboto Startup server. My mentor modified the Ruboto Startup Server to accept extra benchmarks by adding a test name field to the database and renamed the application as Ruboto Benchmark Client from Ruboto Startup Timer. The new app has been deployed to Heroku-server. I tested the new app on various devices and made sure that database is updating on server. I then put my hands over Ruboto Startup timer to generate multiple benchmarks other then startup time. I selected some core benchmarks and added it to Ruboto Startup timer. My mentor added benchmarks for loading rubygems like yaml and active support. In addition he also provided me with TicTacToe and NOOP benchmark. On my part I added some more benchmarks in Ruboto Benchmark client for _“require active_record, “require json” and “require tmail”_. I also tried to benchmark sqldroid by measuring time required in “require sqldroid”, but I was unable to do “require sqldroid” due to some bug in sqldroid. My mentor is looking into this problem and he will notify me as soon as he finds a solution. Additionally Uwe added some JRuby benchmarks like JRuby Runtime pre, JRuby Runtime load, JRuby Runtime prep, Script load and Script resume in the ruboto benchmark client. These entries will be used for later references and comparison as the project will progress.
+</p>
**Week 5-6**
-I added some more benchmarks to the Ruboto Benchmark Client for the proper estimates of time consumed at various stages in Ruboto. I also benchmarked various portions of code in the class JrubyAdapter.java to measure the time taken by them. With the help of my mentors I found out that the first time we do ScriptingContainer#put it instantiates ruby runtime which takes about 6 seconds while any further calls to ScriptingContainer#put takes just 2-8 milliseconds because it doesn't need to re-instantiate ruby runtime. The main task is to improve the time it takes to Instantiate ruby runtime by reducing some of its task or by putting them on hold. I am also looking towards Improving Graphical User Interface of the ruboto app. I have prepared a new layout for the app which has more options than previous one and looks better and is user friendly.
+<p align="justify">
+
+I contacted some other Jruby GSoC Projects and tried to know what other benchmarks are they using for improving JRuby performance, but I came to know that they are not yet focusing on the benchmark part. They will let me know as soon as they will start working on it.
+I added some more benchmarks to the Ruboto Benchmark Client for the proper estimates of time consumed at various stages in Ruboto. With the help of my mentors I found out that the main task is to improve the time it takes to Instantiate ruby runtime by reducing some of its task or by putting them on hold. Therefore I wanted to check what is consuming so much time for loading Jruby in Ruboto. For that I benchmarked various portions of code in the class JrubyAdapter.java and EntryPointActivity.java to measure the time taken by them. I came to the conclusion that the functions fireRubotoActivity and PrepareJruby are major contributors in the Ruboto startup time. The approximate time measurements in emulator are listed below-
+</p>
+>
+>Total Startup Time – 57 sec <br/>
+> &nbsp; &nbsp; &nbsp; &nbsp; PrepareJRuby – 37 sec : calls to put in JrubyAdapter<br/>
+> &nbsp; &nbsp; &nbsp; &nbsp;&nbsp; &nbsp; &nbsp; &nbsp; First method call to put – 36.9 sec<br/>
+> &nbsp; &nbsp; &nbsp; &nbsp;&nbsp; &nbsp; &nbsp; &nbsp; 2nd & 3rd Method calls to put – 25 millisec<br/>
+> &nbsp; &nbsp; &nbsp; &nbsp; fireRubotoActivity – 19 sec
+
+<p align="justify">
+
+i.e. the first time we do ScriptingContainer#put it instantiates ruby runtime which takes the longest time in comparison to further method calls.
+I am also looking towards Improving Graphical User Interface of the ruboto IRB app. I am using some wire framing app first then I will implement it.
+My mentor 'Uwe Kubosch' has been very helpful for making progress in my project, doing these things without his guidance would not have been that easy.
+
-I am also coordinating with one of the main designer and main implementer of org.jruby.embed package containing the ScriptingContainer that we use to access JRuby, for Improving "initializing Ruby runtime". Hopefully will have some gain there.
+</p>
Something went wrong with that request. Please try again.