Skip to content

GSoC 2012 Ruboto Performance and Tooling Mid_term_report

akshay2047 edited this page Jul 5, 2012 · 2 revisions

GSOC MID - TERM REPORT

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.

**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.

**Week 3-4**

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.

**Week 5-6**

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-

> >Total Startup Time – 57 sec
>         PrepareJRuby – 37 sec : calls to put in JrubyAdapter
>                First method call to put – 36.9 sec
>                2nd & 3rd Method calls to put – 25 millisec
>         fireRubotoActivity – 19 sec

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.

Clone this wiki locally