Computing LSTM forward layer without allocating

[robertbastian]

Based on #3349

There's no visible performance difference on our benchmarks, however this avoids an allocation of length codepoints x hidden units, and we only bench on small strings. For longer strings it's probably good to avoid this allocation.

#3305

[zbraniecki]

I can report perf improvement on th lstm from icu-perf

icu4x/th/baked/segmenter/word/lstm/overview
                        time:   [2.6583 ms 2.6646 ms 2.6730 ms]
                        change: [-1.4063% -1.1068% -0.7734%] (p = 0.00 < 0.05)
                        Change within noise threshold.

icu4x/th/baked/segmenter/line/lstm/overview
                        time:   [2.6445 ms 2.6487 ms 2.6530 ms]
                        change: [-1.7483% -1.4729% -1.2153%] (p = 0.00 < 0.05)
                        Performance has improved.

[robertbastian]

Yeah I got the 1% as well but it's nothing to write home about 😀

[zbraniecki]

I'm all for celebrating little wins.

[sffc]

Thanks for making this change

[sffc]

Suggestion (optional): UTF-8 byte order is equivalent to UTF-32 order; it may be cleaner/smaller/faster code if you compared an iterator of char rather than an iterator of u8.

Separately, I'm starting to get a bit worried that the grapheme cluster code may bloat the code size of the LSTM segmenter. We should probably delete it at some point. Maybe as part of the next round of ML model upgrades.

[robertbastian]

The keys are UnvalidatedStrs aka [u8], we cannot use them as anything that's strongly typed.

[sffc]

There is https://docs.rs/utf8_iter/latest/utf8_iter/ for that

[robertbastian]

We don't like deps

[aethanyc]

Segmenter already depends on utf8_iter.

icu4x/components/segmenter/Cargo.toml

Line 35 in b6c4018

utf8_iter = "1.0.3"