Performance of Google’s V8 Javascript engine in Solr

The use of scripting languages to add new functionality to systems is something that I’ve always found very helpful. You don’t have to download the source code of the system, if it has “scriptable” parts you can add simple functionality in minutes without even compiling. Java provides this capabilities in particular with Javascript. You can refer to http://java.sun.com/developer/technicalArticles/J2SE/Desktop/scripting/ for more information on this.

Unfortunately, Java 6’s only included library is Rhino that converts the javascript code into JVM code and its performance is not good. For reasons like these, the scripting languages in general are experiencing something that Java felt itself in the past: the popular belief that they are slow.

The performance is certaintly not that bad but in a critical application, people would prefer to develop native (java) components to keep the performance before losing performance with a probably unnecesary script. This entry is about performance of scripting languages; in particular, other Javascript engines that you can attach to Java.

Google chrome has surprised everyone with their blazing fast javascript engine: V8.

I downloaded V8 and tested it against the regular Rhino option. Actually I didn’t implement the neccesary wrappers to add V8 to Java, nor the JNI C programming necessary as a glue to access V8 functions (which are native in the traditional sense, real machine code running on real processors, like in the old days). I used a library that I found in internet: http://code.google.com/p/jav8/.

For the first test I downloaded a benchmark from V8 that computes an RSA encryption of a text using Javascript. I know, you will feel that I’m cheating by using a benchmark that is not impartial, but the results are pretty conclusive anyway: http://v8.googlecode.com/svn/data/benchmarks/.

The code (download here) also shows the basic usage of the scripting functionality of Java.

public class main {

	public static void main(String[] args) throws FileNotFoundException {

		ScriptEngineManager sm = new ScriptEngineManager();
		FileReader file = new FileReader("test.js");
		ScriptEngine jsEngine = sm.getEngineByName("jav8");

		int iter = Integer.parseInt(args[0]);

		try {
			long acum = 0;
			for(int i=0; i<iter; i++){
				long start = System.currentTimeMillis();
				Object ob = jsEngine.eval(file);
				long end = System.currentTimeMillis();

				acum += end - start;
			}
			System.out.println(acum);
		} catch (ScriptException ex) {
			ex.printStackTrace();
		}
	}
}

I created a simple bash script to run this many times with different number of iterations and these are the results (X has the iterations and Y has the time, so less is better)

The performance difference is outstanding. Particularly interesting is the scalability of V8 when we add more iterations. V8 has an advanced cache system an surely that is helping to keep the performance as the iteration grows.

A real application that performs a set of repetitive tasks is the ScriptTransformer of the Data Import Handler of Solr. This transformer applies a function written in Javascript to each row of a table. This infamous component is something very useful but its performance has always been horrible.

To continue the tests I compared the standard Rhino script engine vs V8 applied to the ScriptTransformer of Solr. I had to modify the ScriptTransformer and remove its “reflection style” implementation (apparently to keep compatibility with 1.5, but quite ugly anyway) to make jav8 work with it. The test consisted in encrypting 5000 records of text from a database. (modified ScriptTransformer.java)

The results:

Again the results show that V8 wins by a big margin.

The conclusion that we extract here is that adding script engines to our systems does not imply that the performance will be damaged. If you accept the use of native libraries (V8 in this case) a script engine can make your systems much more flexible without slowing them down.