StringBuilder is slower than string concat?

[zoilorys]

Hello everyone,
I was experimenting with Gleam and I was doing a lot of HTML string concatenation, so I rewrote logic to string builder. And just for fun decided to try and benchmark how much faster code become in comparison to initial version, so I used Glychee to test it out and to my surprise code actually become slower.
So I created synthetic test with huge number of concatenations and here are the results.

So, the code I used for testing:

import gleam/list
import gleam/int
import gleam/string_builder as sb
import glychee/benchmark
import glychee/configuration

pub fn main() {
  // Configuration is optional
  configuration.initialize()
  configuration.set_pair(configuration.Warmup, 2)
  configuration.set_pair(configuration.Parallel, 2)

  // Run the benchmarks
  benchmark.run(
    [
      benchmark.Function(label: "gleam string concat", callable: fn(test_data) {
        fn() {
          test_data
          |> list.fold(from: "", with: fn(acc, num) {
            acc <> int.to_string(num)
          })
        }
      }),
      benchmark.Function(label: "gleam string_builder", callable: fn(test_data) {
        fn() {
          test_data
          |> list.fold(from: sb.new(), with: fn(acc, num) {
            acc
            |> sb.append(int.to_string(num))
          })
          |> sb.to_string()
        }
      }),
    ],
    [benchmark.Data(label: "range", data: list.range(1, 10_000))],
  )
}

And here are the results

Am I getting something wrong? Maybe there is a better way to use string builder for huge number of concatenations?

[lpil]

Hello! Here's some docs on building binaries (strings and bit arrays)

https://www.erlang.org/doc/efficiency_guide/binaryhandling#constructing-binaries

The string builder (an iolist in Erlang terms) is best for when you need to prepend as well as append, when you have large sub-binaries, and when you want to write the data directly to a socket or file rather than turning it into a string as there is no copying at all in this case.