+ Egor and Benoit, are you looking at the initial page load?

Dear Chrome engineers, hopefully my suggestion will help speed up Chrome loading time. and here is my suggestion.

When Chrome is categorized into two parts, one is "Controller" and the other is "UI".
Now Chrome is initializing "Controller", "UI" and then drawing web page.
If Chrome initializes "UI", draws web page and then initializes "Controller", user will be able to see the web page earlier.
And this initialization order change could make good impact on the web page loading time from the perspective of user experience. 

Dear Chrome engineers,
I have more suggestion and I want you to review them hopefully.

1. Moving "start-up window display" to 2nd activity from 1st activity
Activity launched at first (so called 1st activity) doesn't have a start-up window but activity followed by 1st activity (so called 2nd activity) has a start-up window.
User can see the start-up window at 2nd activity launching moment and it means that all user can see during 1st activity launching stage is a just empty white page.
And it makes user feel a bit of delay.
So if 1st activity is displaying start-up window, start-up time will be improved.

2. Removing additional verityClass() step (Applicable only for 64-bit system devices)
Chrome technically is executed as a 32-bit mode on 64-bit system device and it is requiring additional step, verifyClass() compared to Chrome execution on 32-bit system device.
Chrome is referring external class(gms/app_chimera) and binding it but the problem is there is only 32-bit odex file for this external class.
So Chrome on 64-bit system device should verify this external class since there is no 64-bit odex file Chrome can refer directly.

Hi,

Thanks for the report. I'm not entirely sure that I know which timings you are referring to. Can you give more details on the way the timings were gathered? I suspect this is some script, as timing 96ms visually would be quite hard.

Which device are you running these tests on? With which version of the Samsung browser?

Also, are you closing the browsers between runs?

Regarding the startup setup of Chrome, there are indeed two activities, the first one being transparent and transient, and we know that we have some price to pay because this introduces an extra hop before displaying the UI. But I don't think that it would fully explain the difference between the timings you see.

@mariakhomenko: We are not really looking at startup performance at the moment.

Hi Chrome engineer, here are answers about the questions on Comment8.
Could you check my answers and looking at improving start-up performance?

Q : I'm not entirely sure that I know which timings you are referring to. Can you give more details on the way the timings were gathered? I suspect this is some script, as timing 96ms visually would be quite hard.
A : The timings were gathered using a high-speed camera.

Q : Which device are you running these tests on? With which version of the Samsung browser?
A : Device - Samsung SM-G934L (Galaxy S7 Edge), Version of Samsung browser : 4.0.20-78(Chrome/44.0.2403.133)

Q : Also, are you closing the browsers between runs?
A : Yes, we forcibly stop the browser between runs.

Thanks for the answers!

So, looking at the suggestions in #5:
1. Are you suggesting to remove the first activity, or to make it non-transparent anymore?
2. I'm not really familiar with this verifyClass() step, can you point me at some code location?

1. I'm suggesting to make first activity not-transparent anymore
2. I believe android system trace data would be helpful for you.

Deleted: AndroidSystemTrace_32-bitSystemDevice.zip 1.5 MB

AndroidSystemTrace_32-bitSystemDevice.zip 1.5 MB Download

Deleted: AndroidSystemTrace_64-bitSystemDevice.zip 2.1 MB

AndroidSystemTrace_64-bitSystemDevice.zip 2.1 MB Download

Gentle reminder

We are aware of the slow down due to the first activity, but it has to be invisible because it routes incoming intents to different activities.

I was not able to find anything called verifyClass in the trace data? Perhaps you could point me to a specific point on the timeline?

Regarding AndroidSystemTrace_32-bitSystemDevice.zip, search "com.android.chrome" process and then go down to "UI thread".
On around 800ms, you can see "bindApplication".

Regarding AndroidSystemTrace_64-bitSystemDevice.zip, search "com.android.chrome" process and then go down to "UI thread".
On around 600ms, you can see "bindApplication".

Hi

My understanding was that everything under "bindApplication" is basically framework-level initialization that we have little control over. Your comment implies that this is not the case, can you elaborate on that?

Looking at the Android source code, this trace event comes from a ScopedTrace in the C++ code of ART:
https://android.googlesource.com/platform/art/+/3188364/runtime/verifier/method_verifier.cc#262

Seems like class verification is not something under our control. Is it the case? If so, can you help us?

The point is that Chrome APK for 64-bit system is not executed as 64-bit APK.
Chrome 64-bit APK is executed as 32-bit APK.
And I force to make Chrome 64-bit APK executed as real 64-bit APK and it turns out that verifyClass() time is substantially decreased.


Chrome55_32bitAPK.png : 32-bit APK is executed as 32-bit APK
Chrome55_64bitAPK_32bit.png : 64-bit APK is executed as 32-bit APK
Chrome55_64bitAPK_64bit.png : 64-bit APK is forcely executed as 64-bit APK

Deleted: Chrome55_32bitAPK.png 22.2 KB

	Chrome55_32bitAPK.png 22.2 KB View Download

Deleted: Chrome55_64bitAPK_32bit.png 41.4 KB

	Chrome55_64bitAPK_32bit.png 41.4 KB View Download

Deleted: Chrome55_64bitAPK_64bit.png 21.8 KB

	Chrome55_64bitAPK_64bit.png 21.8 KB View Download

The screenshot shows the culprit dex file being from play services. Maybe the issue is that this is on the critical path?

Sorry that what means by "critical path" but the point is that Chrome 64-bit APK is executed as 32-bit APK and Chrome 64-bit APK MUST be executed as 64-bit APK.
  

Gentle reminder

Gentle reminder

I'm sorry, I'm not really familiar with this part of startup. How do you force a given APK to be executed as 32 or 64 bit?

I believe that we still ship 32bit Chrome on 64bit systems. Is this where the issue manifests itself?
If the fix is to ship 64bit Chrome on 64bit systems, I think that there are significant hurdles, the biggest one being memory usage.

Sorry about the lack of answers, and thank you for helping us make Chrome better!

Appreciated your kind explanation.
But I wonder how many memory usage will be increased if shipping 64bit Chrome on 64bit system.
Will it be twice as big as 32bit Chrome on 64bit system?

I don't know the exact numbers, but the delta is significant.
Not 2x, but in the range of 30-40% IIRC. The biggest difference was observed in V8 and blink.

The main reason is that pointers are twice as big. V8 doesn't support compressed references, and blink is written in C++ (and contains a lot of pointers).

If you want to assess the memory impact, you can build chrome_public_apk and use Chrome remote tracing to compare the memory dumps when the arch is set to arm and arm64 in GN.

Set:
target_cpu = "arm"
or
target_cpu_= "arm64"

in args.gn to change the architecture.

I think we ship ChomeDev as 64 bit, so you can see the difference just between Chrome Stable and Chrome Dev.

As I understand it, there is a desire to address the memory concerns of 64 bit, but I haven't heard an update about it in a while.

Yes, Dev and Beta channels actually ship 64-bit builds to 64-bit phones. The memory concerns are as Benoit describes them. I don't believe there's currently any active work on fixing the 64-bit memory problem.

correction: beta is 32bit

According to the comment 24/25/26, I've downloaded Chrome Dev(59.0.3050.4) from Play Store and installed it on 64-bit system phone.
But it appears that 32-bit Chrome Dev is shipped in 64-bit system phone.
So please correct me if I misunderstand.    

Is this really a loading related performance issue?

The reported "Test for page loading time" seems to be a test to load the Chrome application.

I will remove Performance-Loading label now. If I was wrong, please set the label again.

@toyoshim, this issue is about both "Chrome application loading time" and "Chrome page loading time".
So please set "Performance-Loading" label again since I don't have right to set the label.

*** Bulk edit ***

Setting Feature Requests as: Untriaged 

This regression has been open for half a year. It's not very actionable and the regression has been in all Chrome user's hands for months.