Implement Data.Text.unpack and Data.Text.toTitle directly, without streaming

[Bodigrim]

Related to our discussion with @rhendric at https://discourse.haskell.org/t/the-quest-to-completely-eradicate-string-awkwardness/10111/75?u=bodigrim, let's implement Data.Text.unpack directly via iterArray instead of streaming / unstreaming. My immediate goal is to simplify dependencies between modules of text, but I imagine that performance could get better as well.

[rhendric]

I might be benchmarking this incorrectly, but I think it has a negative impact on performance.

Main.hs

module Main (main) where import Criterion.Main import Data.Text.Internal (Text(..)) import Data.Text.Unsafe (Iter(..), iterArray) import Data.Text qualified as T unpack :: Text -> String unpack (Text arr off len) = go 0 where go !i | i >= len = [] | otherwise = c : go (i + l) where Iter c l = iterArray arr (off+i) {-# INLINE [1] unpack #-} f1 :: String -> String f1 = T.unpack . T.toTitle . T.pack {-# NOINLINE f1 #-} f2 :: String -> String f2 = unpack . T.toTitle . T.pack {-# NOINLINE f2 #-} testInput :: String testInput = "this is a pretty short string, all things considered." testInputT :: Text testInputT = T.pack testInput {-# NOINLINE testInputT #-} main :: IO () main = defaultMain [ bgroup "fusion" [ bench "old" $ nf f1 testInput , bench "new" $ nf f2 testInput ] , bgroup "just unpack" [ bench "old" $ nf T.unpack testInputT , bench "new" $ nf unpack testInputT ] ]

benchmarking fusion/old time 1.148 μs (1.144 μs .. 1.154 μs) 1.000 R² (1.000 R² .. 1.000 R²) mean 1.145 μs (1.141 μs .. 1.151 μs) std dev 16.06 ns (13.55 ns .. 19.22 ns) variance introduced by outliers: 13% (moderately inflated) benchmarking fusion/new time 1.914 μs (1.909 μs .. 1.920 μs) 1.000 R² (1.000 R² .. 1.000 R²) mean 1.911 μs (1.906 μs .. 1.917 μs) std dev 19.80 ns (15.78 ns .. 28.69 ns) benchmarking just unpack/old time 474.1 ns (467.0 ns .. 481.2 ns) 0.999 R² (0.998 R² .. 1.000 R²) mean 470.3 ns (467.4 ns .. 476.1 ns) std dev 12.96 ns (7.541 ns .. 20.76 ns) variance introduced by outliers: 39% (moderately inflated) benchmarking just unpack/new time 943.0 ns (935.2 ns .. 956.6 ns) 0.999 R² (0.998 R² .. 1.000 R²) mean 964.7 ns (956.4 ns .. 972.0 ns) std dev 26.70 ns (23.38 ns .. 31.77 ns) variance introduced by outliers: 37% (moderately inflated) 

[Bodigrim]

Thanks @rhendric, should be fixed now.

[rhendric]

My comment wasn't about toTitle specifically, but about any function with a stream-based implementation. Modify f1 and f2 to use any other function implemented via unstream, and there's still a performance regression. Example:

f1 :: String -> String f1 = T.unpack . T.scanl max '\0' . T.pack {-# NOINLINE f1 #-} f2 :: String -> String f2 = unpack . T.scanl max '\0' . T.pack {-# NOINLINE f2 #-}

benchmarking fusion/old time 836.4 ns (832.7 ns .. 841.6 ns) 1.000 R² (1.000 R² .. 1.000 R²) mean 833.7 ns (831.3 ns .. 837.1 ns) std dev 9.667 ns (6.892 ns .. 14.57 ns) benchmarking fusion/new time 1.085 μs (1.081 μs .. 1.092 μs) 1.000 R² (0.999 R² .. 1.000 R²) mean 1.094 μs (1.087 μs .. 1.104 μs) std dev 27.77 ns (20.48 ns .. 45.82 ns) variance introduced by outliers: 33% (moderately inflated) 

[Bodigrim]

@rhendric we are gradually rewriting all stream-based functions to their non-streaming counterparts. E. g., see map and mapAccumL. Unless you have a particularly long pipeline, non-streaming implementation is faster. If you happen to have a long transformation pipeline (to be honest, I know exactly zero use cases for Data.Text.scanl), you are welcome to use Stream explicitly. See #513 for some context.

[rhendric]

Ah, okay then!