Lately I came across travis-ci.org, which provides a free continuous integration service for projects hosted on Github. I wanted to try the service and thought it would be cool to have CI for the Eclipse EMF ProtoBuf Integration project. Unfortunately it was not that easy and took me a while to set up, but finally I managed.
Today is the last official coding day of Google Summer of Code 2011. With my latest commit updating the README and uploading the P2 repository archive of version 0.1.0 I finished the project just in time. The current version implements all the features mentioned in the original project description. But the development of this project doesn’t stop here. I have several ideas for the future:
After all GSoC was a very interesting experience I would recommend to every student. I would also like to thank my Mentor Cédric Brun for his comments and advice throughout the summer.
… a.k.a. the moment of truth.
At the end of June I finished the first, mostly feature complete version of the ProtobufResourceImpl, which maps, converts and serializes Ecore objects to ProtoBuf. So I started benchmarking its performance in comparison to the existing BinaryResourceImpl. Read more…
After finishing the implementation of mapping and conversion from Ecore to ProtoBuf I wanted to benchmark the performance in comparison to the existing BinaryResourceImpl and XMIResourceImpl. So, I started looking for articles and frameworks for Java performance benchmarks. I found the most interesting article series with the title “Robust Java benchmarking” at IBM developerWorks. It even includes a benchmarking framework, implementing all hints given in the articles. Running the benchmarks with this framework worked and returned sensible results, but two things bothered me: the long execution time of 2-3 minutes for a benchmark run and that it required 3 JARs including a large amount of unused code. Therefor, I looked for an alternative. Besides, I don’t need nanosecond accurate measurements and all the statistics stuff provided by the mentioned framework.
My main requirements for an alternative framework were:
- support for code warmup, so the JIT compiler has a chance to optimize the code
- time measurement with System.nanoTime() instead of System.currentTimeMillis()
- compatibility with Eclipse’ JUnit Plug-in Tests
Here is the list of candidates I assessed and which requirements they met:
I tried to implement the benchmarks with JUnitBenchmarks and Caliper. Although Caliper seemed to be quite promising, it turned out to not work well on Windows and with JUnit Plug-in Tests, because it spawns new JVM processes for benchmarking. I didn’t have these problems with JUnitBenchmarks. The downside of JUnitBenchmarks is that it uses System.currentTimeMillis() and displays results only with a resolution of 0.01 seconds. Actually, there is a discussion on whether to use System.nanoTime() or not. Finally, I decided to use JUnitBenchmarks and could verify the results I got with the “Robust Java benchmarking” framework, but with a much lower overall execution time.
In the next post I will present the benchmark results.
Since the first thoughts about mapping EMF Ecore to Google Protocol Buffers some time has elapsed and I would like to share my results achieved so far.
I started by implementing the “ProtoBuf message per concrete class” mapping. Soon the first problems appeared.
Last week the GSoC welcome package from Google finally arrived. The contents of the package, except the debit card related stuff, are shown below. By the way the debit card has some fancy Google design 🙂
After I prepared my laboratory it is time to start the experiments…
The attentive reader might know that this project is essentially about mapping EMF Ecore models to Google Protocol Buffers (ProtoBuf). So, before I start hacking I should spend some time thinking about how to map Ecore onto ProtoBuf – although I couldn’t resist and already played a bit. These thoughts are necessary, because the Ecore and ProtoBuf “languages” have some major differences.
Outlining the problems and challenges when mapping Ecore onto ProtoBuf is done best by comparing their features.