Reduce monomorphization in Date::try_from_fields and added size measue

[SATVIKsynopsis]

Fixes #7201

This PR refactors the resolve_fields_non_generic() logic in calendar_arithmetic.rs to reduce monomorphization and improve binary size when using Date::<AnyCalendar>::try_from_fields().

It also adds a new example (date_try_from_fields.rs) to measure before and then after binary size differences, as requested.

Binary changes (original file) size comparison:

$ cargo build --release --example date_try_from_fields
$ ls -lh target/release/examples/date_try_from_fields
-rwxr-xr-x 2 kiit kiit 588K Dec 6 17:17 date_try_from_fields

$ strip target/release/examples/date_try_from_fields
$ ls -lh target/release/examples/date_try_from_fields
-rwxr-xr-x 2 kiit kiit 460K Dec 6 17:18 date_try_from_fields

After changes size comparison:

$ cargo build --release --example date_try_from_fields
$ ls -lh target/release/examples/date_try_from_fields
-rwxr-xr-x 2 kiit kiit 576K Dec 6 17:20 date_try_from_fields

$ strip target/release/examples/date_try_from_fields
$ ls -lh target/release/examples/date_try_from_fields
-rwxr-xr-x 2 kiit kiit 452K Dec 6 17:21 date_try_from_fields

This demonstrates a measurable reduction in monomorphized code size.

The stripped example binary decreased from 460 KB (before) to 452 KB (after), a net savings of ~8 KB (~1.7%).

This reduction comes from refactoring resolve_fields_non_generic() to avoid monomorphizing calendar-specific logic
into generic code paths.

[robertbastian]

Thanks for running benchmarks, the size reduction looks promising! However, I don't think it makes sense to review this as long as it changes behaviour. Please make the tests pass.

[SATVIKsynopsis]

I have pushed a fix for the CI failures from the last commit.

Previously, I achieved an 8 kB reduction, but that code failed the tests because I had simplified the year/era logic too much. I realized I removed some necessary calculations that specific calendars need.

I have fixed that now. Here is what I did in this new version:

I moved all the data preparation into a prepare helper function.

I moved all the final checks and error handling into a finalize helper function.

The main function now just sits in the middle and calls the specific calendar methods using the data from the helpers.

This approach is safe and passes all tests. The size reduction is now about 6 kB (~1.3%). While this is slightly less than the previous 8 kB reduction, the logic is now fully correct and now and the CI issues will pass.

The size successfully reduced from the original file which was 460 kb to 454 kb.

[sffc]

$ cargo build --release --example date_try_from_fields

Could you add this code to the pull request?

[SATVIKsynopsis]

That file was breaking CI tidy request so I removed that from commit history. I will add it as asked now.

[SATVIKsynopsis]

I have added the example file as asked.

[sffc]

Thank you. Could you make it use #![no_main] and icu_benchmark_macros as we do in other examples? See here:

https://github.com/unicode-org/icu4x/blob/main/components/icu/examples/iso_date_manipulations.rs

It removes a lot of standard library code from the binary which helps you get better code size readings.

[SATVIKsynopsis]

I have updated the file to use #![no_main] and the icu_benchmark_macros as you suggested, aligning with the pattern in the iso_date_manipulations.rs example.

[sffc]

Thanks; can you re-measure the size impact now?

When building, I suggest using --profile release-opt-size

[sffc]

I mean, what is the size of the example before and after the change to the try_from_fields code?

I have a suggestion: please open a separate PR for the example, because then we can easily track in the dashboard what is the impact of this PR on the code size.

[SATVIKsynopsis]

Using --profile release-opt-size, the results are:

Before: ~341 KB

After: ~343 KB

This profile adds its own instrumentation, so the change appears slightly positive.
However, under the normal --release profile, the size still improves (460 KB → 454 KB), confirming that the refactor has a net positive impact.

[sffc]

We've spent time making sure that --profile release-opt-size gives a reliable measurement of code size, better than --release. If you're not seeing an improvement with that profile, it means that more work is needed on the PR.

Please start by making a separate PR for the example that measures code size; there are more changes I'd like to suggest over there. Then, this PR can cleanly evaluate only the library code change. It might take some experimentation to figure out how to reduce the code size.

[robertbastian]

You should run cargo make wasm-wasm-examples for platform-independent size benchmarks. This is what gets tested in CI (https://unicode-org.github.io/icu4x/benchmarks/binsize/wasm/index.html)

[SATVIKsynopsis]

Are there any final changes or checks you would like me to perform on this PR as the dependent example file PR is already merged? Thank you.

[robertbastian]

Please update the benchmark numbers. The baseline is ~40KB

[SATVIKsynopsis]

Thank you for confirming the official baseline of ~40 KB.

I also tested on my local toolchain using a clean build. On my machine, the wasm output reports ~56 KB, which appears to be due to local overhead and differences in the build environment.

However, the structural change in this PR removes approximately 6 KB worth of monomorphized code paths, and the difference shows up consistently in the native binary (--profile release-opt-size).

Given that the official CI environment produces the established 40 KB baseline, the same structural reduction should apply there as well.

[sffc]

On main:

$ cargo make wasm-wasm-examples
$ ls -l wasmpkg/date_try_from_fields.wasm 
-rwxr-xr-x 1 sffc primarygroup 47052 Dec  9 17:17 wasmpkg/date_try_from_fields.wasm

I tried running on this branch, but you need to remove the old example from this branch and merge in the new example from main.

[SATVIKsynopsis]

I have removed the old example file from this branch as requested, which resolves the build conflict.

The PR now contains only the final, optimized calendar arithmetic file.

[sffc]

I checked out your branch and merged in main locally to get a measurement.

$ cargo make wasm-wasm-examples
$ ls -l wasmpkg/date_try_from_fields.wasm 
-rwxr-xr-x 1 sffc primarygroup 59394 Dec  9 19:38 wasmpkg/date_try_from_fields.wasm

So there is a 26% size increase.

Now that you have a specific thing to measure against, please continue experimenting until you get the file size down.