That&#x27;s bizarre.<p>One thing I&#x27;ve noticed is that performing the string scanning operation is relatively cheap. (If the splitAndTrim code is modified to not use Strings and to return a [String.UTF16View], the runtime is around 1.2 seconds.) It&#x27;s the process of building Strings out of those UTF16 views that is destroying performance.<p>I still don&#x27;t know why changing the way the input data are constructed would have that effect, except to guess that the underlying representation is different somehow. I&#x27;ll file a ticket.