The performance characteristics of data providers

[gregtatum]

I've been trying to understand the performance characteristics of the data providers, and what the end goal will look like.

As was discussed previously, the FsDataProvider is bad as a production-ready provider. This definitely shows in the profile. Most of the time is spent in slow IO operations. This was also what was showing up in our Firefox integration testing.

• FsDataProvider: https://share.firefox.dev/3xJ8OOt
• Benchmark: 5053ms

With the static data provider, there is already a huge improvement.

• StaticDataProvider: https://share.firefox.dev/3ANKcq7
• Benchmark: 1946ms

The next big chunk of timing seems to be the deserialization, which takes 56% (1,092ms) of the time in the DateTimeFormat components case. In my mental model moving the Patterns to the data provider was that this would make them very low-cost to instantiate, but there still seems to be a lot of cost to validate and allocate what we are pulling out.

I know there has been work with yoke and zero copy to make things faster, but I'm unsure if this is getting close the final performance characteristics that we expect.

In Firefox at least we will initially hook ICU4X data in using the static data provider and place the data in the binary. This is what we are currently doing with the ICU4C data, so I'm expecting these test cases to match the Firefox behavior pretty closely until/if we support dynamic data loading and a blob provider.

[sffc]

DateTimeFormat is not set up yet with zero-copy deserialization; this is tracked in #876. I anticipate that hooking up the DateTimeFormat data with Yoke/ZeroVec will have a performance improvement based on previous benchmarks:

https://unicode-org.github.io/icu4x-docs/doc/zerovec/index.html#performance

Zero-copy is nice because it is a win on both performance and memory. However, if you want yet a further performance boost and are okay with increased memory consumption, #919 is the tracking issue for DateProvider caching, which means you can cache the deserialized object after you touch it for the first time.

[sffc]

Looking at your flame graph, I see that a large chunk of deserialization time is spent in malloc calls. This would indicate that if we can eliminate the need to call malloc, we should see a performance win.