1

I'm currently working on a project which requires JS support (actual program written in C#) and am using Jint as the interpreter. Before I did any further work, I ran a basic performance test to find the difference between a compiler (E.g. Chrome V8) and an interpreter. I expected a 50x slowdown at most, but what I found was closer to 600x. Chrome's V8 took 60-100ms, while Jint took 60 to 70 seconds.

The tests I used were Mozilla's Dromaeo String tests - http://dromaeo.com/?dromaeo / http://dromaeo.com/tests/dromaeo-object-string.html, with a couple of minor modifications to work without using the DOM. 

var sTime = new Date();
var startTest = function(){sTime = new Date();};
var test = function(name, fn){ fn(); };
var eTime = new Date();
var endTest = function(){eTime = new Date(); console.log(eTime.getTime() - sTime.getTime());};
var prep = function(fn){ fn(); };

So, my question is: Why is Jint between 600 and 1000 times slower than V8 / native compiliation? Are interpreters really that much slower or is this just a special case where Jint is especially slow?

EDIT I have posted my test code here: http://pastebin.com/R017KKvR

It seems that string.lastIndexOf is the problem, taking 24-26 seconds to complete that test.

Colorfully Monochrome
  • 994
  • 7
  • 19

1 Answers1

1

I will assume you are using Jint v2 or greater.

V8 will always be faster, in almost every scenarios. As you are mentioning the question is really by how much. In this case this could come from two factors:

  • how much does interpretation impact the time to execute the script
  • how well and optimized are the String prototype methods implemented

The only way to answer this is to actually profile the performance of the script which is executed and understand where the time is consumed. A simpler first approach could also to trace each different grouped method calls to determine if the overall time might come from only one or two of them.

You might have found a huge performance bug too which I would really be happy to fix.

Update

Fixed with this commit: https://github.com/sebastienros/jint/commit/2ed825cda866092c728b07a9e2b6109b0d20cbc8

Sébastien Ros - MSFT
  • 5,091
  • 29
  • 31
  • I have updated the question with the requested info. It seems that `lastIndexOf` takes anywhere from a third to three-quarters of the total test time. – Colorfully Monochrome Nov 25 '14 at 18:21
  • It takes more than that so let's assume this is something we should look into definitely. Assuming all the tests should have approximately the same impact. – Sébastien Ros - MSFT Nov 26 '14 at 21:56
  • On Chrome's V8 compiler, the `lastIndexOf` test takes approximately 15 ms, compared to 8 for the `indexOf` operator. So, it's about 2x as long. – Colorfully Monochrome Nov 26 '14 at 22:00
  • If it can't wait or it interests you, please create a PR with a fix. Just take the indexOf implementation from StringPrototype.cs and use it as a template. Please disregard the current implementation which is more complex for historical reasons. The unit tests will be started automatically on your PR. – Sébastien Ros - MSFT Nov 26 '14 at 22:12