Code size ballpark analysis (as of June 2021)

[sffc]

A couple customers have recently asked for code size analysis of ICU4X versus ICU4C, so I thought I would share some ballpark figures.

Methodology

I compared ICU4X FixedDecimalFormat against ICU4C NumberFormatter. This is not a completely fair comparison, for reasons listed in the Analysis section, but it gets us a ballpark. I compiled code_line_diff.rs and a port of that example to C++.

ICU4X

I ran the following command from the current tip of the main branch (acf3886):

$ RUSTFLAGS="-C panic=abort -C opt-level=s" cargo +nightly-2021-02-28 build -Z build-std=std,panic_abort -Z build-std-features=panic_immediate_abort --target x86_64-unknown-linux-gnu --release --example code_line_diff

Note that the s opt level is used; this means to optimize for size.

There were to changes I made to the code file:

1. Removed #[cfg(debug_assertions)] on line 47 to force the println! to be included in the binary
2. When testing with no data, I replaced icu_testdata::get_provider() with icu_provider::inv::InvariantDataProvider

The WASM numbers were taken in the same way, except with wasm32-unknown-unknown instead of x86_64-unknown-linux-gnu, and I took a sample with only icu_provider::inv::InvariantDataProvider since icu_testdata::get_provider() is not well defined in WASM.

ICU4C

I used the following code_line_diff.cpp:

#include <unicode/utypes.h>
#include <unicode/locid.h>
#include <unicode/numberformatter.h>
#include <unicode/errorcode.h>
#include <unicode/ustream.h>
#include <iostream>

struct Int64Pair {
    int64_t _0;
    int64_t _1;
};

const Int64Pair LINES_REMOVED_ADDED[] = {
    { -50, 72 },
    { 0, 3750 },
    { -1201, 0 },
    { -9876, 5432 },
    { -5000000, 3000000 },
};

int main(int _argc, char* _argv[]) {
    icu::ErrorCode status;

    icu::Locale locale("bn");

    auto lnf = icu::number::NumberFormatter::withLocale(locale)
        .sign(UNUM_SIGN_ALWAYS);

    for (const auto& line : LINES_REMOVED_ADDED) {
        auto removed = lnf.formatInt(line._0, status);
        auto added = lnf.formatInt(line._1, status);
        std::cout << "Added/Removed: "
            << removed.toTempString(status)
            << "/"
            << added.toTempString(status)
            << std::endl;
    }

    return 0;
}

To compile this code, I first compiled ICU4C with static linking and then used the following command:

$ g++ -Os \
	-I/path/to/lib/icu4c_69_1_static/include \
	-L/path/to/lib/icu4c_69_1_static/lib \
	code_line_diff.cpp \
	-licui18n -licuio -licuuc -ldl \
	stubdata.cpp \
	-o code_line_diff

As with Rust, the -Os opt level is used.

stubdata.cpp is a file I used to removed libicudata from the resulting binary:

extern "C" {
char* icudt69_dat = "";
}

To get the size for only the data loading code by itself, I used the following cpp file, compiled the same way as above:

#include <unicode/utypes.h>
#include <unicode/ures.h>
#include <unicode/errorcode.h>
#include <iostream>

int main(int _argc, char* _argv[]) {
    icu::ErrorCode status;
    ures_open(NULL, "en", status);
    return 0;
}

Computing binary size

To compute the binary size for x86_64 executables, I used the following command on the resulting executable:

$ size -A -d path/to/executable

This command prints a "Total" line, which is what is reported in the table below.

For WASM executables, I took the file size of the .wasm file.

Raw Results

The following figures are binary code size, without data.

Case Study	Total Binary Size	Binary Size (Core+I/O)	Binary Size (Data Loading)
ICU4X FixedDecimalFormat (x86_64)	129905 B	25677 B	104228 B*
ICU4X FixedDecimalFormat (wasm32)	32985 B	not measured	not measured
ICU4C NumberFormatter (x86_64)	2102688 B	1554075 B*	548613 B

* These values are computed by taking the difference of the other two measurements in the row.

Analysis

First, NumberFormatter is a "kitchen sink" class that does much more than FixedDecimalFormat. This likely accounts for most of the difference between the core library size. However, ICU4C does not currently have an ability to split monolithic classes such as NumberFormatter (and many others) into smaller pieces. (Disclaimer: I wrote both FixedDecimalFormat and NumberFormatter and can speak to this as being different design considerations.)

On the data loading code size, it is interesting that ICU4C is about 5x the size of ICU4X (548 kB vs 104 kB). Almost all of the ICU4X code size for data loading is dedicated to Serde deserialization, which we are actively working to optimize (#78). The ICU4C code size for data loading is largely dominated by locale handling functionality, including horizontal and vertical fallbacks. ICU4X's data pipeline is designed to avoid the need for horizontal fallbacks, but vertical fallbacks are not yet implemented and will likely be needed.

My best explanation for the code size difference between x86_64 and wasm32 is that wasm32 does not include any file I/O for data loading, since file I/O is unavailable in WASM, and the compiler likely dropping that code entirely.

Conclusions

• Out of the box, without other optimizations applied, ICU4C is about 2 MB in code size, whereas ICU4X is currently 130 KB.
• ICU4C includes much more functionality in the minimal example than ICU4X due to deliberate class design.
• I expect ICU4X to decrease in size once How should we build static data? #78 is fully implemented.

[zbraniecki]

This is super helpful, thank you Shane!

For 0.1 I did ICU4X 0.1 vs ICU4C 67 comparison using a harness, and got size diff for DateTimeFormat, PluralRules, Locale and Unicode Set - https://docs.google.com/spreadsheets/d/1SnbL7OEshSOv7QrEIxUK8FA0FYzuZOZ-r9g8r5oLwAQ/edit#gid=0

In 0.1 DTF did not have some important pieces like TimeZones, which take a lot of data, but we knew we're designing the system to not have to load it if not in use, so I think the results can be assumed to give us a ballpark as well.

The tests were performed by writing a small Rust/C++ app and plugging a single component at the time, compiling and measuring impact.

• DateTimeFormat, Binary impact: ICU4C - 2,088,156b, ICU4X - 214,872b (-90%)
• DateTimeFormat, Data impact: ICU4C - 8,678,116b, ICU4X - 427,000b (-95%)
• PluralRules, Binary impact: ICU4C - 155,176b, ICU4X - 182,064b (+19%)
• PluralRules, Data impact: ICU4C - 33,880b, ICU4X - 18,000b (-45%)
• Unicode Set, Binary impact: ICU4C - 29,624b, ICU4X - 16,664b (-45%)
• Locale, Binary impact: ICU4C - 153,432b, ICU4X - 33,072b (-79%)

In #66 I am updating the numbers to 0.2 vs ICU4C 69. I hope to have some results within a week.