Overal, optimizing the parser for speed yields an 5.5% improvement on the jQuery benchmark in Speedometer, and 4.1% on VanillaJS, with an overall 1.5% improvement on the total score. I've measured on a nexus 6, on the perf bots. I've added more bots (nexus5, nexus5x) to confirm the results, but overall it seems pretty positive.

On the negative side, the increase in binary size is 77k. The breakdown from the diagnose_bloat.py script is:

MonochromePublic.apk_Breakdown (+77,824 bytes)
        -3 bytes Zip Overhead
   +77,824 bytes Native code size
        +3 bytes Package metadata size
MonochromePublic.apk_Specifics
   +77,824 bytes normalized apk size
   +77,824 bytes main lib size

I'm attaching the detailed output.

Experimental CL: https://chromium-review.googlesource.com/c/chromium/src/+/782140

Overall, I think this is worth doing, Andrew, do you have any thoughts about the tradeoff?

Deleted: diff_results.txt 436 KB

diff_results.txt 436 KB View Download

We might be able to trim that by confining the set of affected source files further (IIUC presently it's everything in core/html/parser/, but things like the tokenizer are likely to be more impactful than some of the other files. This would complicate the build a little, though.

Interesting! Looks a bit unlikely that you'd be able to shrink significantly by being more selective. Much of the size is in the first couple screens of symbols, and they come from files that seem pretty core.

You'll want to test on a low-end device as well to see what the effect is there (we have a Go device if you'd like to borrow it).

77kb isn't small, but it's in the realm of doable if there's a clear win. I'm not really familiar with the benchmarks though, so maybe we could ask the benchmark owners if they think the results are significant?  We could also just commit it for a while and see if any perf metrics change.

Regarding the importance of the benchmark, Speedometer is one of the most important benchmarks in the web platform. All browsers are competing on the performance :)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b9fddd03657a4b15506833bf7678a51785094dc7

commit b9fddd03657a4b15506833bf7678a51785094dc7
Author: Lucas Furukawa Gadani <lfg@chromium.org>
Date: Wed Nov 22 22:55:17 2017

Optimize HTML parser for speed instead of size on Android.

Bug:  787512 

Change-Id: Ib04d450fbb6d6f8ba389e378df8c4d5d8b643965
Reviewed-on: https://chromium-review.googlesource.com/782140
Commit-Queue: Lucas Gadani <lfg@chromium.org>
Reviewed-by: agrieve <agrieve@chromium.org>
Reviewed-by: Jeremy Roman <jbroman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#518781}
[modify] https://crrev.com/b9fddd03657a4b15506833bf7678a51785094dc7/third_party/WebKit/Source/core/html/BUILD.gn
[add] https://crrev.com/b9fddd03657a4b15506833bf7678a51785094dc7/third_party/WebKit/Source/core/html/parser/BUILD.gn

 Issue 788221  has been merged into this issue.

Looking at today's perf bots, the performance improvements are significant, almost 10% improvement on the jQuery benchmark in Speedometer, see https://chromeperf.appspot.com/report?sid=1ac3a8fed5a246dcae2e84bd5e443e193eca18daa836be4cbeac7604be4a3748 .

That's awesome! I'm certainly in agreement that this is "worth it" :). Closing.