Anticipated binary size impact from change to base::Feature

[Jan Keitel]

Dear all,

As part of https://chromium-review.git.corp.google.com/c/chromium/src/+/7918651 we are planning to add the ability to default-enable a base::Feature only in certain countries. This matches a capability that already exists server-side. To achieve this, we plan to add an additional member to base::Feature that encodes country restrictions.

This change will result in an APK size increase that violates the limit for low-end phones. It would increase the APK size by 37.6 KB.

Normalized APK Size: 37620 bytes (max is 16384 bytes)
Normalized APK Size (arm64): 104304 bytes (max is 6553600 bytes)

Are there any objections from this group to making this change?

Thank you,

Jan

[Daniel Bratell]

(This is not a formal objection)

Why does the binary grow that much?

/Daniel

--
You received this message because you are subscribed to the Google Groups "binary-size" group.
To unsubscribe from this group and stop receiving emails from it, send an email to binary-size...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/binary-size/77f75edf-fd23-41f2-9a43-8ced56d39d2en%40chromium.org.

[Jan Keitel]

Ultimately, because there are a lot of features in Chrome.

You can see in the APK breakdown that every feature grows by 8 bytes on a 32 bit system - presumably the 4 bytes for the pointer in the span and 4 bytes for the span's size.

[Andrew Grieve]

It'll be double the size for 64-bit, and the size is entirely in .data, so will consume memory per-process.

It looks like you've considered lots of alternatives in your doc: https://docs.google.com/document/d/1xVgnPJqikxdb7yXFrMSp_jzheHSXlSAXWMyN57_XMrU/edit?tab=t.0

My gut is that we should find a way to not increase the size for features that don't use it. I don't have a good grasp of how common this is, but if it's not too common, would it solve the problem to add a base::get_variations_country() and base::set_variations_country()? It's less ergonomic to have to check the flag and the country, but it would avoid per-feature overhead. Alternatively, we have a lot of codegen related to features already, so maybe we could store country data in a separate structure that is generated by a script (the doc points out it can't be inline due to constexpr)?

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/binary-size/ace128e5-e2f7-42b9-9327-a4d943af964dn%40chromium.org.

[Jan Keitel]

Andrew,

Could you explain a bit more what you are proposing? To make sure we're on the same page: We do not need a global variable in base that holds the variation country (we store that just once in base::FeatureList), but, instead, we need to store for every base::Feature whether it has any country inclusions/exclusions.

Jan

[Andrew Grieve]

On Tue, Jun 16, 2026 at 9:56 AM Jan Keitel <jke...@google.com> wrote:

Andrew,

Could you explain a bit more what you are proposing? To make sure we're on the same page: We do not need a global variable in base that holds the variation country (we store that just once in base::FeatureList), but, instead, we need to store for every base::Feature whether it has any country inclusions/exclusions.

E.g. a global std::map<> of feature name -> enabled countries.

[Jan Keitel]

Some thoughts/concerns on that:

Dynamic initialization is a no-go for variables with static storage duration. Therefore we have two choices:

- Somehow add the country information to features somewhere at run time during browser startup. That seems odd, in particular for features that are defined outside of an embedder.

- Have magic codegen that scans the entire codebase and creates a single constexpr map from that, e.g. directly in base. Seems error prone and tricky to get right, e.g. just making sure that you don't encode superfluous country information for features that do not end up getting linked into the specific binary.

Do you have any specific examples/precedents in mind?

In meantime, I'll explore some base::FeatureWithCountryRestriction variants that either inherit from base::Feature or use composition to see whether we can address the binary size concern that way.

[Andrew Grieve]

On Tue, Jun 16, 2026 at 10:36 AM Jan Keitel <jke...@google.com> wrote:

Some thoughts/concerns on that:

Dynamic initialization is a no-go for variables with static storage duration. Therefore we have two choices:

Why is it a no-go? Chrome has lots of statics that are mutable...

- Somehow add the country information to features somewhere at run time during browser startup. That seems odd, in particular for features that are defined outside of an embedder.

- Have magic codegen that scans the entire codebase and creates a single constexpr map from that, e.g. directly in base. Seems error prone and tricky to get right, e.g. just making sure that you don't encode superfluous country information for features that do not end up getting linked into the specific binary.

Do you have any specific examples/precedents in mind?

I was thinking just have a file similar to field_trial_testing_config.json that could store tha mappings, and codegen from that. 

 

In meantime, I'll explore some base::FeatureWithCountryRestriction variants that either inherit from base::Feature or use composition to see whether we can address the binary size concern that way.

Thanks! I think it'll be worth trying to prevent the per-feature overhead. 

[Jan Keitel]

On Tuesday, June 16, 2026 at 4:59:40 PM UTC+2 agr...@chromium.org wrote:

On Tue, Jun 16, 2026 at 10:36 AM Jan Keitel <jke...@google.com> wrote:

Some thoughts/concerns on that:

Dynamic initialization is a no-go for variables with static storage duration. Therefore we have two choices:

Why is it a no-go? Chrome has lots of statics that are mutable...

Yes, but it does not have lots of static that initialize themselves using global variables from elsewhere.

 

- Somehow add the country information to features somewhere at run time during browser startup. That seems odd, in particular for features that are defined outside of an embedder.

- Have magic codegen that scans the entire codebase and creates a single constexpr map from that, e.g. directly in base. Seems error prone and tricky to get right, e.g. just making sure that you don't encode superfluous country information for features that do not end up getting linked into the specific binary.

Do you have any specific examples/precedents in mind?

I was thinking just have a file similar to field_trial_testing_config.json that could store tha mappings, and codegen from that. 

 

I agree that something like that could work. I don't love having feature definition and country information in separate places. It would make things such as compiling/linking only the necessary country information depending on platform and unit testing harder. Let me try the base::FeatureWithCountryRestriction idea first.

Thanks for the input!