slow JS / C++ bridge

[farfromrefug]

I decided run some tests comparing perfs of the actual runtime vs v8 runtime. One thing which worries me quite a bit is the "bridge time". I have made a test to run this function on an array of 100000 points. On the current runtime it takes around 60ms. With the v8 runtime it takes around 300ms. That means a 5x slower runtime in a sense :s The test was made on simulator.

Dont know if anything can be done about this. Would love to get your view on this

[farfromrefug]

Jut to add on this why it worries me. One already existing case where you get fast native calls is requestAnimationFrame which makes calls to __tns_uptime at a high framerate.

[darind]

Thanks for the observation. We will look into this and report back any findings.

[darind]

@farfromrefug, could you please provide a sample illustrating the slowdown?

I have tried the following method:

class Path {
    constructor() {
        this.path_ = CGPathCreateMutable();
        CGPathMoveToPoint(this.path_, null, 0, 0);
    }

    lineTo(x, y) {
        CGPathAddLineToPoint(this.path_, null, x, y);
    }
}

let count = 400;
let point = new Path();
console.time("perf");

for (var x = 0; x < count; x++) {
    for (var y = 0; y < count; y++) {
        point.lineTo(x, y);
    }
}

console.timeEnd("perf");

and it produced similar results with both runtimes.

[farfromrefug]

@darind can you try with 10000 points? With not many points it was small enough to not be seen

[farfromrefug]

@darind sorry misread your example. It was actually 400 * 400 calls ... Just ran it again with your latest:

• ios-runtime : 87ms
• ios-v8-runtime: 400ms

[darind]

@farfromrefug, we have released several fixes that should improve the performance of method calls. Running this test in release mode on an iPhone X (iOS 13.2.2) yields the following results:

• ios-runtime: 80ms
• ios-v8-runtime: 91ms

The new runtime is still a bit slower but we are getting closer and the difference is quite insignificant.

Can you verify if you are observing improved performance with your tests?

[farfromrefug]

@darind really awesome! Amazing work as always! Will test that tomorrow

[darind]

@farfromrefug, we have released some additional perf improvements that have closed the gap between the beta and the official runtime.

[farfromrefug]

@darind with 6.5.0-beta.2-v8-2020-01-29-122856-01 : *ios-v8-runtime: 157.827ms *ios-runtime: 80.945ms

Seems to be the best i can get

[darind]

@farfromrefug, on what device are you running the test? I am getting identical results for both runtimes on an iPhone X (app built in release mode).

[farfromrefug]

@darind it was on an iphone 6 simulator. Will try and run more tests. Does it make a difference on simulator/device?

[darind]

@farfromrefug, running on simulator can make a huge difference. As a rule of thumb, when making performance tests make sure that you are building in Release mode, targeting arm64 architecture and running on a real device.

[farfromrefug]

@darind good to know sorry about the wrong results then! Will confirm next week that it is fully ok. Ok with you?

[darind]

That’s perfectly fine. Thanks for proactively testing the beta and reporting any issues you encounter with it!

[farfromrefug]

@darind just ran the test on my iphone 5s:

• 6.5.0-beta.2-v8-2020-01-31-100851-01 : 900ms
• 6.4.0: 399.303ms

Still a big difference here

[darind]

@farfromrefug, here are the results of my measurements:

model	official	V8 beta
iPhone 5s	255ms	581ms
iPhone 6	250ms	580ms
iPhone 6s	107ms	169ms
iPhone 7 Plus	85ms	108ms
iPhone X	80ms	80ms

It appears that for those kind of operations the V8 based runtime performs better on more recent hardware. Unfortunately the profiling of the code doesn't indicate any possible paths of improvements in the iOS runtime itself.

Google engineers have assured me that they are still improving the performance of V8 when running in jitless mode and I will continue to monitor for newer releases which could perform better on older chips.

[NathanaelA]

@farfromrefug - Thanks for pushing on this; I am all about performance too. I appreciate seeing the real numbers and understanding the tradeoffs. Excellent idea testing the marshaling performance.

@darind - Awesome benchmarks you presented, thanks very helpful. Sometimes we have to take a performance hit for the greater good -- and that is very hard for me to say. :grinning: In my case I am a very very strong believer in unifying the engines; the ability for the App to run the exactly the same on both runtimes is critical for moving forward at a more rapid pace. I am aware of several issues where JS on JSC is different than JS on v8, which has already created issues in the repos from people who don't understand why the app (typically) broke on JSC.

It is very unfortunate that the marshaling is a up to 57% slower on older devices, but in all reality it is only .002ms slower on the iPhone 5s in v8 per call ( if I am doing my math correctly )... :grinning: So, this might cause some issue for some more corner case situations on older phones (Sorry Martin!). Most apps aren't doing heavy loops to/From Native (which I've always recommended you don't do) So, imho, the Marshaling hit should actually not be a factor in the vast majority of apps.

Since iOS is running Jitless; and the v8 jitless mode is brand new -- the actual better question is on the JS side what is the performance of actually running in the JS side. How quickly does a test app start on JSC vs v8 on the same device? Is the whole app slower; or is the app faster? What about the time from first JS code being ran; to app being fully ready, to get a better idea of how much faster/slower v8 vs jsc is on a lower/higher end iOS device.

[farfromrefug]

@NathanaelA indeed the question is more on an app fluidity than on the use case presented here. But is was the easiest way to actually test it. Would love to see tests of running apps. And I like to always use an low end device. It is the best way to improve things to the max :p

[farfromrefug]

I just thought of an important use case where c++/js bridge can make a big difference : listviews. I have to run some test but with complex list view templates this can make a difference. I am facing this right now(both ios and android)