Enable is_high_end_android

[Kaz205]

Improves Speedometer 2.0 scores on Chromium 117 from 44.8 to 77.1, a whopping 70% performance improvement, all while having smaller binary size (227mb -> 203mb).

Note that this enables relr, which is only supported on API 28 and up. Furthermore, PGO profiles must be fetched as mentioned on https://chromium.googlesource.com/chromium/src.git/+/master/docs/pgo.md

[kiwibrowser]

Hello Kazuki,

Very interesting finding! PGO Profiles are already in use in Kiwi, so it shouldn't be too complicated to enable this flag.

I will test the flag this week, normally this is available for testing in about 10 days, if this is actually supported by the 116. series (which the in-progress remaster/near full-rewrite of Kiwi is based on)

Arnaud.

[DVergil]

I expect future improvements in the decoding part

[Kaz205]

Hello Kazuki,

Very interesting finding! PGO Profiles are already in use in Kiwi, so it shouldn't be too complicated to enable this flag.

I will test the flag this week, normally this is available for testing in about 10 days, if this is actually supported by the 116. series (which the in-progress remaster/near full-rewrite of Kiwi is based on)

Arnaud.

@kiwibrowser
I'm pretty sure it's supported in 116. Did it work?

[kiwibrowser]

Yes it did, however as Kiwi was already using PGO profiles the difference isn't that obvious, the new build comes today.

I am using the PGO profiles that the Chromium team recommends (the mac-arm), but I wonder if there is enough overlap with Android arm devices or this (obviously, Chrome team sees that it works, and I should believe them based on results, but there is a significant additional performance gain to grab if we start instrumenting specific traces for Kiwi).

So the next step would be to do our own traces on a device using chrome_pgo_phase=1.

However, interesting and related finding while investigating further the PGO profiles: changing settings for ThinLTO actually had impact : the import_instr_limit (by raising the limit to 30) is somewhat better than 5, while slightly increasing the binary size (1MB).

The most important will be to compare on your device, whether Kiwi is faster than Chrome or not.

The device that I use to test Kiwi is an entry-level device (it is a Samsung Galaxy A04s) and Kiwi is very fast there.
So let's see with the import_instr_limit further later today (it is enabled with a limit of 30), and is_high_end_android of course.

[Kaz205]

Yes it did, however as Kiwi was already using PGO profiles the difference isn't that obvious, the new build comes today.

The device that I use to test Kiwi is an entry-level device (it is a Samsung Galaxy A04s) and Kiwi is very fast there. So let's see with the import_instr_limit further later today (it is enabled with a limit of 30), and is_high_end_android of course.

Thanks for the reply. Considering that my benchmark was done on a Snapdragon 780G, it's possible that the -O2 optimizations caused more cache usage and slowed down your CPU which has smaller cache.

I was actually planning to suggest using -O3 which increased perf by quite a lot on my M1 Mac, but considering the small cache size on mobile CPUs, maybe it's not a very good idea.

[Kaz205]

This is a bit embarrassing, but it appears that my phone throttles quite quickly and I didn't notice it was throttling when I took the initial benchmarks. I retook the benches and here are the results:

Kiwi 116 (no extensions and adblock): 97.8
Chrome 114: 94.77
Chromium 117: 99.31

So around the same as other optimized browsers and on par with what you'd expect.
https://blog.chromium.org/2023/04/more-ways-were-making-chrome-faster.html