Consider setting InvariantGlobalization in api template

[eerhardt]

API server applications often don't need to consider culture behavior. The data flowing in and out of the application is created and consumed by other applications (not humans). This data is typically in a culture independent format because it is consumed by other applications.

We should consider adding <InvariantGlobalization>true</InvariantGlobalization> to the dotnet new api template. This can easily be removed by the app developer, if their API app needs culture aware behavior. Alternatively, if we really thought the decision should be directly made by the user, we can make it an optional checkbox in the template dialog in VS.

Enabling InvariantGlobalization brings with it some nice performance benefits.

On Windows x64, the BasicMinimalApi using EnableRequestDelegateGenerator=true, the app size goes from:

main: 9.70 MB (10,179,072 bytes)
InvariantGlobalization: 9.48 MB (9,945,600 bytes)

It also appears to help with startup times (linux-x64):

main: Start Time (ms) | 40
InvariantGlobalization: Start Time (ms) | 37

And memory consumption (linux-x64):

main: Working Set (MB) | 47
InvariantGlobalization: Working Set (MB) | 43

cc @DamianEdwards @davidfowl @mangod9 @tarekgh

[richlander]

If we make this choice, we need to provide guidance on which container image we recommend.

[DamianEdwards]

I'm supportive of this, especially doing so initially in the preview cycle so that we can get further feedback. Having the property directly in the project file makes it fairly discoverable too. We should ensure that the MSBuild core schema file includes an entry for this property if it doesn't already, and additionally we should look at getting the VS project property pages UI updated to support this setting this property VS UI too.

[MichalStrehovsky]

Is there no way to make this pay-for-play automatically? I'm just wondering why we're ending up loading ICU on the startup path. If we're not doing any culture specific things, I would not expect ICU to get loaded at all (and affect startup time/working set).

I would even expect it to be trimmed away, but that one might be just wishful thinking, given I see a KoreanLunisolarCalendar, and various other calendar types even in a fully trimmed hello world app).

[jkotas]

There are two metrics to consider for pay-for-play:

Binary footprint pay-for-play

Unfortunately, basic runtime services depend on current user culture. For example, formatting of numbers in exception messages depends on the current thread culture that is initialized to default user culture by default that brings dependency on ICU. It is not feasible to break this dependency without behavior change.

InvariantGlobalization setting introduces such behavior change by disabling everything that has to do with cultures. It may be possible to come up with settings that are a subset of what InvariantGlobalization does, for example a setting that changes the default thread culture to invariant culture. The downside is that it would make the globalization space even more complicated.

I think it makes sense to set InvariantGlobalization in the api template for good footprint and omit ICU in the recommended container base image.

Startup time pay-for-play

You have made a good point that we should not need to load ICU for api startup. It is very easy to dependent on current user culture by mistake. I see that the ICU gets loaded by a culture-specific string.Compare call in event source manifest parsers that looks like a bug. We may want to do some onion peeling to see whether fixing bugs like can move us far enough.

[JamesNK]

I think it's weird to disable this on one template. If it should be disabled on this template, why not on all templates?

The size and startup improvements are pretty minor. I think this kind of setting is better to document on a page that discusses AOT + reducing app deployment size. People who really care, and don't need gloablization, can update their project to use it.

[tarekgh]

This template is for server apps which most likely not need globalization support. I will be concerned if we turn off globalization by default on other templates.

[JamesNK]

Got it. By all templates I was thinking about all server templates

[richlander]

The size differences are not minor when you factor in container-based deployment.

Our Debian and Ubuntu images contain ICU and our Alpine images do not. Ubuntu Chiseled images also do not.

As both Jan and Tarek suggest, changes to globalization are observable. We do our best to help developers achieve wins where it makes sense. This whole space has a lot of gotchas.

Server templates isn't really a specific enough category, right?

[DamianEdwards]

We're only talking about disabling it in this one template, specifically the new "api" template. We could also consider disabling it in the existing "webapi" and "worker" templates for the same reasons outlined already (i.e. they're typically not serving content to human readers).

[captainsafia]

Triage: We'll also want to make sure that the InvariantGlobalization property is documented.

We'll also want to consider enabling this for gRPC templates.