Is there any benchmark testing for segmenter wrt ICU4C WordBreakIterator?

[riajain0412]

We currently use ICU4C WordBreakIterator for our use case. Recently, we came across ICU4X so thought of trying its wordBreakSegmenter. I analyzed the data size difference between ICU4C and ICU4X for WordBreakSegmenter for SEA languages and found that ICU4X's data size is slightly larger than ICU4C's data size and on the other hand your LSTM data size seems to be very less.
So I have below 2 queries:

1. As dictionary based segmentation data size is slightly large than our ICU4C data size so I want to know that how ICU4X's performance is better than ICU4C? Although the data size difference is in few KB's but we use it for WASM and even few KB's becomes a great deal for us because of WASM.
2. For LSTM based segmentation, I want to know it's accuracy details as well as how much is the latency if we use this model wrt to dictionary based segmentation?

[Manishearth]

ICU4X will likely be faster during data loading. However, note that our segmenter modules are experimental and we have not yet made the data fully zero copy, so there will be some situations where it's not as fast as it could be. When the segmenter modules are finished we will likely always be faster than ICU4C on data loading as we are in every other component.

For segmentation performance, I haven't measured it myself, but I think @zbraniecki has? I'll let the others give more specific answers as they have more context.

cc @makotokato @sffc @aethanyc

[sffc]

I don't have up-to-date numbers on the performance difference between dictionary and LSTM. But, even if I had microbenchmarks, they don't really tell the whole story about how the segmentation strategy affects the overall performance of a text layout engine in practice. If you segment one screen's worth of text at a time, it's unlikely that there will be a latency difference. If you are segmenting many pages of text, then segmentation becomes more critical to app latency and you may notice a difference.

I would actually be quite interested if you could take the performance measurements in your own context and share them.

[Manishearth]

Relatedly: what is your context? What are you attempting to build with ICU4X?

[riajain0412]

I don't have up-to-date numbers on the performance difference between dictionary and LSTM. But, even if I had microbenchmarks, they don't really tell the whole story about how the segmentation strategy affects the overall performance of a text layout engine in practice. If you segment one screen's worth of text at a time, it's unlikely that there will be a latency difference. If you are segmenting many pages of text, then segmentation becomes more critical to app latency and you may notice a difference.

I would actually be quite interested if you could take the performance measurements in your own context and share them.

Okay, Got it. Let me check what I can do to get performance measurements

[riajain0412]

Relatedly: what is your context? What are you attempting to build with ICU4X?

With ICU4X, I want to use WordBreakSegmenter for all the platforms(Win, Mac, android, wasm etc.) I'm currently using ICU4C for this so just wanted to analyze how is ICU4X better than ICU4C and what extra does ICU4X have to offer.

[Manishearth]

Right, but what are you building using the segmenter?

[zbraniecki]

I analyzed the data size difference between ICU4C and ICU4X for WordBreakSegmenter for SEA languages and found that ICU4X's data size is slightly larger than ICU4C's data size

@aethanyc @makotokato - do we understand the reason for ICU4X data to be slightly larger than ICU4C?