Seems mostly Blink-main thread bound which is mostly doing V8.  It looks like the 3 other cores are mostly idle while one core works on that.  iPhone 6S is dual-core with better single-core performance so it could account for much of the difference.

One idea I had to make a proper comparison on the same hardware is to install Android on a jailbroken iPhone.  There are posts online on doing that, although jailbreak methods are rarer than they used to and tend to become obsolete rapidly.

Hmm, is this all because of single core performance? That is sad.

+Blink>Loader to see if there's anything loading can do, while it seems a lot of V8 needs to run on single core is likely the cause.

One thing to try would be to see if there's a difference in network requests and payloads. That is, are we comparing apples to apples?

+Ross as we just chatted about this in the speed convergence. V8 team's working on off-loading compilation task to another thread, as well as going to use multiple threads for parsing, so we expect that it'd probably make this better.
We're also starting to do more evaluation on V8 code caching, which should also potentially save v8 runtime for repeated visits.  We plan to regularly revisit this to track.

Dimitri: I think that's also a good point, we could check that too.

I just grabbed a trace on a Pixel with V8 runtime call stats enabled.

A lot of the time is spent in V8 (~3 seconds of CPU time), and the largest bucket is C++ runtime bucket - at 23% (733ms). Unfortunately it's a fairly long tail of actual runtime functions - the top 5 make up less that 15% of that time:

GetProperty		187.554 ms	108539	5.895%
CreateObjectLiteral	71.341 ms	6701	2.242%
RegExpExec		71.104 ms	1998	2.235%
KeyedGetProperty	50.362 ms	32662	1.583%
HandleApiCall		39.814 ms	26683	1.251%

Toon / Camillo - does anything stick out - could we reduce any of these runtime calls on CNN? GetProperty sticks out - should we be calling into it so often?

Deleted: trace_cnn (1).json 8.4 MB

trace_cnn (1).json 8.4 MB View Download

The GetProperty calls are a bit suspicious, but that might just be for API objects (DOM elements), I remember cnn doing a crazy amount of DOM manipulations.

We might have a got at it with --trace-ic to see whether this is really the case (or quick manual instrumentation).

The NextAction date has arrived: 2017-12-01

I grabbed another trace with a Pixel on m66 (which includes the code-cache after execute work in crbug.com/808007).

The overall load-time seems much improved, down to around 2.6 seconds now, so close to the iPhone 6S numbers mentioned in #0. Most of the main-thread time is still spent in V8 (~2.2s), thought the mix is a bit different now (presumably some changes in the website have also impacted this).

 - Compile + Parse is down from 749ms to 244ms, so there is a significant improvement due to code-caching after execute (most of the compile time is now spent deserializing the code-cache) \o/.
 - Executed JS is down a bit (713ms -> 573ms) - possibly just changes in the JS being run.
 - V8 C++ is down a lot, from 713ms to 344ms. Looking at the breakdown of top C++ runtime calls, it looks like GetProperty has pretty much gone, and  CreateObjectLiteral has been has much reduced runtime (similar call count, but much faster):
  
    RegExpExec 				86.049 ms	3192	3.753%
    Map_TransitionToDataProperty	57.410 ms	31771	2.504%
    RegExpReplace			26.594 ms	20788	1.160%
    HandleApiCall			20.432 ms	33634	0.891%
    CreateObjectLiteral			17.682 ms	4551	0.771%
    StringSplit				9.625 ms	4627	0.420%


I'm going to close this since we seem much closer to Mobile Safari - Grace feel free to re-open if you think we are still substantially behind.

Deleted: trace_trace_cnn_pixel2.json 4.6 MB

trace_trace_cnn_pixel2.json 4.6 MB View Download