IronJS – Function call overhead benchmark

After battling all night with the DLR to get decent function call performance I think I’m close to what will be the final implementation for dispatching function calls, here’s a quick benchmark, same contestants as yesterday.

The benchmarking code looks like this:

var y = function (a) {
    var x = function (_) { };

    for (var i = 0; i < a; ++i) {
        x(i);
        x(i);
        x(i);
        x(i);
        x(i);
        x(i);
        x(i);
        x(i);
        x(i);
        x(i);
    }
};

time(function () {
    y(1000000);
});

The new compiler lags behind V8 with about 40% on the call overhead, but here it is C# vs C/C++ rearing its ugly head and I just don’t think I can squeeze any more performance out of it. TraceMonkey really shows the performance of it’s tracing JIT compiler here (which benefits immensely from tight loops with many repeated calls) and beats out both V8 and IronJS.

The current dispatch system does not use the one that is delivered with the DLR, it incurred to large of an overhead to be usable if I wanted to compete with the market leading runtimes. The call system in place uses an if/else statement to switch between using the JavaScript-dispatcher for JS function calls and the normal DLR dispatcher for .NET inter-op calls.

There were a few voices raised about the uselessness of micro-benchmarks like this, and while I agree to an extent – the performance of dynamic languages depend heavily on three things:

• Static analysis and JIT:ing, to make as many variables as possible statically typed
• Call overhead, how much time is spent in the runtime itself instead of executing the requested function
• Property access, how long of a time it takes to get/set properties of objects

My goal with these benchmarks are to show a hint of the performance you can expect from IronJS in these areas.