[Performance] Investigate performance of the DFG and FLT JITs

[ide]

We should take advantage of the JIT if we can. Opening this issue so we don't forget about it. cc @kmagiera @astreet

[astreet]

We're running with the JIT enabled, but DFG and FTL JITs disabled. I'm running experiments now with DFG/FTL enabled, initial results aren't showing any perf improvements in feed rendering but I'm going to double check tomorrow.

[ide]

Ok thanks. FTL seems like it could help because RN apps are longer-running than most mobile webpages. Just a guess.

[astreet]

Yeah, that's true. I'm testing just for the initial renders of feed since that's the metric most important to us, but it'd also be great to do a long-running-app test. The cost for DFG+FTL seems to be ~.5MB extra binary size.

[kmagiera]

As @andrews said: JIT is enabled, we don't use DFG and FTL. Closing this as I ensured that it is a while ago.

BTW: ~.5MB is uncompressed for single CPU arch? or for x86+armv7?

According to http://trac.webkit.org/wiki/JavaScriptCore DFG kicks of after 60 calls for methods. For perf tests we can just have 60 warmup runs to ensure that all the methods are called at least 60 times

[astreet]

I think we should actually keep this open to make sure we explore DFG/FTL under longer-running conditions.

[ide]

@kmagiera Thanks for the verification. If you gather data about performance with the DFG and FTL (1000 runs I believe) I would be interested in seeing it. I expect there are some hot code paths inside of libraries like Animated that will run over 1000 times that could benefit from specialization.

(Updated this issue description since the topic changed a bit.)

[astreet]

Thanks James!

(An important thing I already noticed in my investigation is that there isn't any noticeable negative effect before those JITs kick in.)

[ide]

One of the engineers who works on WebKit says about the different JIT modes: "When verifying perf, make sure they really run. FTL only runs if it can successfully load LLVM." https://twitter.com/awfulben/status/647556134383947776

The docs say, "Your mileage may vary, though, since currently only Mac and iOS is supported by the FTL JIT. " https://trac.webkit.org/wiki/FTLJIT

So it sounds like we might not be able to enable FTL.

[kmagiera]

That link to trac is 14months old. We managed to compile JSC with FTL JIT, would be good to actually verify it runs

[dryganets]

You can't just enable FTL as it's only supported for 64 bit code.
It's not true for most of android devices.

[glcrazier]

Now B3 JIT compiler was introduced. possible to upgrade JavaScriptCore?

[dryganets]

I think it's possible.

I just enabled the DFG_JIT
on synthetic octane test it shows 2x improvement in pure JS speed.

[glcrazier]

May I wonder if there is any progress about it?

[dryganets]

We try DFG_JIT on our project. Synthetic octane tests show 2 times performance improvement.
Though that doesn't have any impact on the application performance. So we decided to switch back to the original JSC as startup became visible longer after this change.

Also from my experience of work with UWP on the desktop where chakra shows 30k octane though perceptional application performance is the same.

If you having problems with performance on react-native you'd better review your data flow through the bridge rather than spending time on optimization of js engine.