Editors Note: This is a post that’s part of a series on Platform Engineering at Appcelerator.

This is the first in a series of blog posts from the Appcelerator Engineering team on upcoming platform improvements planned through the rest of this year. Performance of applications on Android has been on the radar for quite some time and the technology has progressed to the point where we can finally address it in a meaningful way.

First some background. A Titanium implementation on a mobile platform must provide a JavaScript runtime in order for your applications to run along with our unique compiled bindings code. We compile these bindings into source code depending on the platform – it’s native to the environment such as Java for Android and Objective-C for iOS. However, during runtime, we still require a JavaScript runtime to provide dynamic evaluation of code, events, etc. The JavaScript runtime ends up being a critical part of the performance of any application. While we get maximum performance (at least in theory) on the native bindings side, we also have to deal with the performance of the engine to be able to have the best performant applications.

Our Android implementation uses a Java based interpreter, Rhino, due to Android OS limitations on the devices we support. Rhino has been around for a very long time and was first built by Netscape (now Mozilla) as an open source project. Rhino is also fairly popular in server-side products that leverage JavaScript. However, Rhino has been around for a long-time and isn’t actively under development and suffers from several Java-based limitations. For Android, up until around the late summer, we didn’t feel like we had too many other choices and focused all of our performance improvements in the binding layers where we could make impacts. We did make a few minor improvements to Rhino but most of our effort centered around our own code.

Early in the spring we started an internal project to port Titanium to V8 – which is Google’s JavaScript runtime built from the ground up around Chrome. V8 is used by some amazing products such as NodeJS, Android, ChromeOS and WebOS – among many others. V8 is also very actively developed by Google and licensed under an open source friendly license.

Up until recently, we had a dilemma with attempting to bring V8 into a production release. In order to use V8 (which is in C/C++), we had to wait for Google to provide a stable Native Development Kit (NDK) which provides application binary interface (ABI) compatibility to different CPU architectures. This all happened with 2.2 and now that the market for older release has dropped significantly, we now feel confident we can fully switch Titanium to V8 and massively improve performance. We typically drop support for older platforms when their market presence as reported by the Android Market Statistic page drops to 10% or lower.

In our testing, the V8 runtime is performing two times that of the current Rhino runtime and we can expect much higher performance gains once we fully get this ready. The V8 port is under active development and we hope to have the beginning of a development branch soon. We are also continuing to address performance issues in the Rhino implementation as it will continue being offered since not all Android implementations support the Android NDK yet (like Google TV).

Sun spider comparisons

The following are the results of the Sun Spider tests.

Javascript to Java bindings

Pseudo code used: Test Case with 10,000 iterations of JS->Java bridge

Rhino: Direct java binding by implementing org.mozilla.javascript.Function

V8: C++ binding using a function pointer, function pointer invokes JNI -> Java class / object

Test platform / hardware:

Android 2.2 (Froyo)
HTC Evo

Runtimes:
V8 from the Froyo 2.2 branch
Rhino 1.7.3 CVS

Object and Prototype accessors

Code used:
Test Case of 50,000 iterations of setting properties to an empty object on a custom prototype, and again on an object instance (100k iterations total)

Test platform / hardware:

Android 2.2 emulator, default AVD options
T-Mobile G-Slate, Android 3.0.1
HTC Desire, Android 2.2
iPhone 4, iOS 5.0 beta

Runtimes:

V8 from the Froyo 2.2 branch
Rhino 1.7.3 CVS
titanium_mobile revision f7c0117 (+ TiCore)

As you can see from the raw performance results, V8 looks to perform even better the iOS in a lot of cases.

Release Timing

At this moment, we don’t have a specific release date but we are working very fast to bring this release to market with a target for late Fall. As you might imagine, adding another runtime is a non-trivial task, so we will be testing that the Rhino and V8 implementations behave the same before we release V8. We are significantly expanding our unit test coverage this past quarter and focused on bringing more tests online before we finalize the release.

Other performance improvements

V8 isn’t the only performance improvement we’re working on – although it is significant. We are looking at a number of other performance improvements such as introducing a new declarative UI which will allow us to compile the UI into a native compiled UI (such as layout XML for Android and NIB for iOS) as well as providing much more hooks to allow us to optimize the native code bindings.

How you can help?

Application Testing

If you have an application that you’re having problems with for Android related to performance, please let us know by emailing community@appcelerator.com. We’d like to build up a set of real life applications that we can use for regression testing as well as performance testing our new builds against in QE. If you don’t mind sharing your source code and helping us ensure it runs on our side, we’ll use this as part of our larger test bed.

Unit Testing

We really need help with writing unit tests. We have a team dedicated to writing tests but the API set is large and growing. We use a test framework called Drillbit that is easy to run and included when you fork the code from Github. It’s easy to add new tests and we can run these tests automatically.

Hiring

We are constantly hiring here at Appcelerator – especially on the platform team. Right now we have 4 open positions on the Android team. If you’re interested in Android and hacking on V8, please let us know by applying at http://jobs.appcelerator.com.

What’s coming next?

As this is the first in a series of post from Engineering I’m going to mention additional topics to be covered in our weekly to bi-weekly updates.

- Demo and more performance information of V8 vs Rhino on Android (Next Post)
- Changes to API documentation that we’ve been working on since April
- Behind the scenes look at Engineering processes
- API parity effort
- Features upcoming in the next mobile release 1.8.0

In my next post which we should have ready by next week, we’ll provide a demo of the performance of a running test application for you to view. Until then, Codestrong!

• 

This entry was posted on Wednesday, September 7th, 2011 at 11:47 am and is filed under Android, Mobile. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.