All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=923929

(For debugging:) Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?sid=6d4cf00e77d6fe2272ce7e8c168048c280fb81989fdc619d24c3016b8acd9436


Bot(s) for this bug's original alert(s):

Android Builder Perf

Assigning to frechette@chromium.org because this is the only CL in range:
Return more than a single language with ULP language code locator.

- Modifies UlpLanguageCodeLocator and its helper functions to support more than a single quadtree.
- Adds second and third most spoken languages data, and modifies BUILD process to embed them into the helper functions.
- Augments the test for this extended functionality.

Bug: 850947
Change-Id: Ie2c44bbb562d8905454fb2dcf594d7eb4df9a3b4
Reviewed-on: https://chromium-review.googlesource.com/c/1409606
Commit-Queue: Alexandre Frechette <frechette@chromium.org>
Reviewed-by: anthonyvd <anthonyvd@chromium.org>
Cr-Commit-Position: refs/heads/master@{#624169}

Note that the trybot appears to have computed a size ~50 bytes below the threshold.  Hence no alert.  

https://ci.chromium.org/p/chromium/builders/luci.chromium.try/android-binary-size/138755

Question still holds though.  Is this an expected change?  Is it avoidable in any way?

This size difference is to be expected as we are adding raw data to help us infer better languages for users in India. Effort was put in to compress this data as much as possible (data consists of raw bits that is de-serialized into specialized data structure).

Sounds good.  Thanks for the quick response!

Wonder if the raw bits are also compressed? Worth at least checking out (e.g. run it through gzip or out/Release/clang_x64/brotli to see if they would shrink a bunch more if compressed. if 50% or more, than probably worth it.

I do not get any compression with gzip.