slow JS / C++ bridge about ios HOT 19 OPEN

@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?

from ios.

@farfromrefug, here are the results of my measurements:

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.

from ios.

@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

from ios.

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)

from ios.

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.

from ios.

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

from ios.

@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.

from ios.

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

from ios.

@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

from ios.

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

from ios.

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

from ios.

@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

from ios.

@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).

from ios.

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

from ios.

@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.

from ios.

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

from ios.

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

from ios.

@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

from ios.

@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. 😀 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 )... 😀 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.

from ios.