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!