Add Ultimate String Guide

[hasufell]

TODO:

• short overview table for picking string types
• string classes
• overloadedstrings extension
• conversions (e.g. cheat sheet table)
• a few words on lazy IO with Text/ByteString
• streaming libraries as an alternative for string types
• JSString?
• mention streamly quasiquoter: https://streamly.composewell.com/haddocks/streamly-core-0.2.2/Streamly-Unicode-String.html#v:str

Rendered: https://github.com/hasufell/hasufell.github.io/blob/strings/posts/2024-05-07-ultimate-string-guide.md
(The html color codes in the UTF-8 table do not show)

---

@Bodigrim this isn't completely finished yet, but I would appreciate a review regardless.

Pinging a couple of other folks if they want to drop some comments: @tomjaguarpaw @mpilgrem @angerman @Ericson2314 @bgamari

[mpilgrem]

@hasufell, looks good! A couple of thoughts:

• you might acknowledge the existence of the Haddock documentation in Data.Char (which is more elaborate than the Haskell Report) and in Data.String (which does explain the performance considerations);

• you may recall that one thing I was stuck on was filepaths and FromJSON instances. Could an 'ultimate' guide capture your advice there?

[Bodigrim]

Very nice!

[Bodigrim]

For an ultimate guide it would be great to mention:

• byteslice aka unpinned ByteString aka sliceable ShortByteString.
• text-short which is like ShortByteString but for Text (used in aeson IIRC).

[hasufell]

@Bodigrim now I'm actually wondering what is the advantage of ShortByteString over Bytes?

From what I understand:

• slightly more space efficient: takes up two Int records less (seems quite minor)
• since it doesn't do slicing, everything is effectively a copy (tail, init, splitAt,. ..), allowing GC to clean up early

The latter is a bit of a weak argument though, isn't it, given that you can just clone Bytes back to e.g. a ShortByteString.

Did I miss anything?

[hasufell]

I'm also trying to figure out the exact memory overheads of all types. But I'm not very deep in that topic: https://gist.github.com/hasufell/61ca8ef438cc912e7446bcc7b1f25028

[Bodigrim]

@Bodigrim now I'm actually wondering what is the advantage of ShortByteString over Bytes?

On a modern CPU memcpy is extremely fast, so it could be faster just to copy data than manipulate two Int fields with offset and length. Also a bit less indirection in runtime, a bit less memory pressure (which is useful to fit into CPU cache).

I'm also trying to figure out the exact memory overheads of all types. But I'm not very deep in that topic: https://gist.github.com/hasufell/61ca8ef438cc912e7446bcc7b1f25028

I wonder if https://hackage.haskell.org/package/weigh-0.0.17/docs/Weigh.html could be of any help. Also maybe try ghc-vis (but it probably does not account for {-# UNPACK #-}, see below).

For lists we have list constructor tag (essentially, (:)), then field with a pointer to Char, then field with a pointer to the rest of the list, which is 3 words. Char takes 2 words: one for constructor C# and another for unboxed Char#. Altogether 5 words per character. Empty list object is shared by all lists in the program, so effectively it does not contribute.

For Text bear in mind that {-# UNPACK #-} of a monomorphic strict field kinda "inlines" it, so there is no constructor tag.

[Bodigrim]

Manuals for weigh:

• https://haskell.foundation/hs-opt-handbook.github.io/src/Measurement_Observation/Haskell_Profiling/weigh.html
• https://www.fpcomplete.com/blog/weigh-package/

Also it would be interesting to try https://github.com/def-/ghc-datasize