Playing with V8 JavaScript engine in .NET

I was toying with Google Chrome's V8 JavaScript engine in .NET code  last night, and ran some crude benchmarks on JSON parsing out of curiousity.

The results were interesting, but predictable. Newtonsoft's JSON parser is known to be one of the fastest (see bar chart on its Codeplex homepage).

Time taken to parse a simple JSON string in a loop of 1000 iterations:

In the benchmarking test fixture cited above, the libraries had been initialised in the warm-up phase of the test setup. However, I the three libraries exhibited very different warm-up characteristics, which may be worth considering for less frequent or one-off parsing operations. I ran a separate benchmark in which I initialised the library in a loop of 20 iterations. There's obviously much more to V8 than just parsing JSON, and this took on average 9 iterations to warm up, and 138ms for 20 iterations, and carried significant overheads. Perhaps this is why the application crashed if  the loops were much larger! The framework's built-in JavaScriptSerializer class initialised with consistent speed after the first slow iteration, and took 69ms for 20 iterations. Newtonsoft's parser also fully warmed up in the first iteration, and took 126 ms for the 20 iterations. These data obviously need to be more granular, the first "cold start" iteration being the slowst and most important.

I'm curious to know what the bottleneck is with V8. E.g. Is it the C wrapper? Transferring data to and from the library? Or the V8 run-time? Etc. This could of course be investigated further, e.g.  by passing in extra JavaScript to get the time before and after the parsing, if I ever get a chance. 

I'd like to run the test again with a much bigger and more complex JSON object with multiple levels of child objects. I'd also like to compare the framework's DataContractSerialiser too, to make it a more comprehensive benchmarking suite.

This was not a scientific test, just a quick eperiment, and there is obviously more to consider in JSON parsing than the points of interest that I present above.

18 June 2013

Share the love:

Comments: 6

Add Comment

Consider trying V8.NET as well. :) I'd be interested to see the results.

Tim Acheson (19 Jun 13, 22:24)

@James I will do, I'll add that to my test fixtures and update this page with the results. I gather you've put a lot into performance tuning recently. It could help highlight the impact of the wrapper its self on the results. The real killer with the javascriptdotnet wrapper for V8, and something which doesn't necessarily show up in simple benchmarking results, is object initialisation and disposal. Thus, rapid consecutive creations of the object by a thread quickly kills the application. It'll be interesting to see if your work with GC can reduce that type of performance degredation in a loop. I suspect the real bottleneck is V8 its self, but we'll see! :)

You already know that this is music to my ears:

"I've carefully crafted a C++ proxy wrapper to help marshal fast communication between the V8 engine and the managed side."

I speculated that this factor may have been an important bottleneck with javascriptdotnet V8. Your special attention to this area reenforces my original suspicions, and your V8 wrapper could help provide the key to answering this question...

Then you'll be glad to know the recent release now uses a pure stack-only handle and no GC internally (and externally as long as you dispose them manually using "Dispose()"). My console app (included in the release) already comes with a bench test for accessing managed side properties, and compares the speed with the native side. :)

Tim Acheson (25 Jun 13, 13:59)

@James Awesome, thanks for letting me know! :)

JSON.NET provides indeed the feature-richest JSON deserializer, well-tested and supported, and also pretty fast. But ServiceStack's is even faster. For instance, see [ ]. There's also this new kid on the block (of my own, in less than 600 SLOC, much shorter than the former), pretty close to ServiceStack's performances :

Enjoy :)

Sorry, new home:


  • Twitter
  • LinkedIn
  • Facebook
  • Windows Live / Messenger
  • Xbox Live
  • RSS
  • Email