Changing baked data to use zerotrie

[robertbastian]

No description provided.

[sffc]

Have you measured impact on binary size and performance?

[sffc]

While I think we should explore this, there are some factors at play that might make ZeroTrie less compelling for baked data than for blob data:

1. The compiler is able to deduplicate locale strings across DataProvider lookup tables, which it did not do in blob1
2. binary_search is a primitive that the compiler could figure out how to optimize on its own, whereas ZeroTrie provides only one algorithm for the lookup

My suspicion is that despite these factors, ZeroTrie will still be faster and smaller overall, although to a lesser degree than it was in blob1 vs blob2. I would however like to see some figures.

[sffc]

^ Pending metrics.

[sffc]

Do you have metrics?

[robertbastian]

Yes in the diffs

[robertbastian]

You should review #5161 first, as it says in the description.

[sffc]

Nit: I'm in support of changing the impl Iterator to a concrete type, but I don't want to restrict the concrete type to being a specific map composition like this. Please introduce a new type such as ZeroTrieAsciiIterator or something like that so we can change the internals in the future. Safest would be to have a different type for all four concrete impls.

[robertbastian]

And these four types redirect all 76 iterator methods to the types they wrap?

[sffc]

Fair point, we can clean this up later before zerotrie 1.0

[robertbastian]

I've made a #[doc(hidden)] type alias, should be non-clickable in the docs

[sffc]

Praise: Impressive size reductions, and this is a fair comparison when converting TinyStr to ZeroTrie since those are both reference-less structures.

[sffc]

Hash map instability was creeping in somewhere?