Why use text-builder instead of text's Builder ?

[KtorZ]

Hello!

I was on my way to make a PR to get rid of text-builder in favor of the builder API already available in text when I noticed:

b3bfa93

and wondered what motivated this change? The commit doesn't say much, hence the issue.

Thanks for the clarification.

[mitchellwrosen]

It's faster and doesn't take nearly as long to compile modules that use it.

[KtorZ]

Interesting!

I haven't run the benchmarks from that repository but I am mildly skeptical about it. In the same way that jsonifier was said to be faster than aeson and is for some chosen benchmarks but in practice isn't really for real-life data; it's actually even worse.

Given how widely used and battle-tested is text, I think I'll stick with it for now 😊 (see the fork here in case you wish to point anyone to it). I am pretty satisfied with its speed.

Thanks for the library; works like charm!

[mitchellwrosen]

Oh? I'm interested! Indeed my investigation only involved looking at and running the benchmarks in the text-builder repo. But I'm very eager to see benchmarks that show otherwise.

And either way I could be convinced to again drop the dependency and go back to text. But first I'd like to get to the bottom of whether text-builder is truly faster at concatenating strict Text than text.

[mitchellwrosen]

I converted this to a "discussion" - hopefully that doesn't bury it!

[mitchellwrosen]

@KtorZ To clarify -- which of these were you interested in? (Or something else?)

1. Drop the text-builder dependency (and thus the Text.Builder.ANSI module, since text doesn't ship with a strict Text builder)
2. In Text.ANSI, round-trip through Text.Lazy.Builder.ANSI rather than Text.Builder.ANSI

[KtorZ]

(1) it is :)

Since this is a library meant to construct text by parts, I think it's fine if the API works with builders only.