Golang中fmt.Sprintf与字符串拼接的性能对比

Golang中fmt.Sprintf与字符串拼接的性能对比 大家好！我在测试一个简单的函数时注意到，fmt.Sprintf 的基准测试结果似乎比直接拼接字符串要慢得多。我猜它在底层做了更多的事情。内存基准测试结果也似乎更差。是我看错了基准测试结果，还是误解了它们？我应该尽量避免在简单的字符串拼接中使用 fmt.Sprintf 吗？这是一个微不足道的微优化，我不需要担心吗？谢谢！

fmt.Sprintf("One for %v, one for me.", name)

// BenchmarkShareWith-12            2779749               428.4 ns/op           128 B/op          6 allocs/op

"One for " + name + ", one for me."

// BenchmarkShareWith-12           20134160                59.12 ns/op            0 B/op          0 allocs/op

更多关于Golang中fmt.Sprintf与字符串拼接的性能对比的实战教程也可以访问 https://www.itying.com/category-94-b0.html

3 回复

感谢您阐明这一点，这完全说得通。

我的函数如下所示：

// concat ver:
func ShareWith(name string) string {
	if name == "" {
		name = "you"
	}

	return "One for " + name + ", one for me."
}

// fmt ver:
func ShareWith(name string) string {
	if name == "" {
		name = "you"
	}

	fmt.Sprintf("One for %v, one for me.", name)
}

// benchmark test (from exercism go track https://exercism.io/my/tracks/go):
var tests = []struct {
	name, expected string
}{
	{"", "One for you, one for me."},
	{"Alice", "One for Alice, one for me."},
	{"Bob", "One for Bob, one for me."},
}
func BenchmarkShareWith(b *testing.B) {
	for i := 0; i < b.N; i++ {

		for _, test := range tests {
			ShareWith(test.name)
		}

	}
}

那么，编译器是在字符串拼接版本中做了一些自动优化，而这些优化在 fmt 版本中无法实现吗？

非常感谢您的帮助！

更多关于Golang中fmt.Sprintf与字符串拼接的性能对比的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html


格式化字符串的速度较慢。Sprintf（或Printf、Fprintf等）的参数必须包装成interface{}类型，然后放入[]interface{}切片中，接着需要解析格式字符串中的格式化指令，创建一个底层缓冲区，然后将解析后的格式字符串写入其中（例如，先写入"One for "，然后使用name参数的值计算%v指令。name在运行时被检查是否为string类型（我推测），并写入缓冲区，随后是", one for me."）。接着，缓冲区被复制到一个新的string中并返回。

如果你正在编写数字的十进制表示、格式化time.Time或其他自定义数据类型，这种开销可能是值得的。如果你有两个字符串需要连接，直接相加即可。对于三个或更多字符串，我通常会在代码中加入这个函数：

func concat(strs ...string) string { return strings.Join(strs, "") }

然后像这样使用它：result := concat("One for ", name, ", one for me.")

在你的具体情况下，基于0 allocs/op，我的第一猜测是编译器在编译时知道了name的值（name是一个常量，还是在代码中稍早几行仅从常量赋值而来？），并将你连接的字符串转换为单个常量。

从基准测试结果来看，你的观察完全正确。fmt.Sprintf 确实比直接字符串拼接慢得多，原因如下：

  1. 反射开销：%v 格式化符需要运行时反射来确定值的类型和格式
  2. 内存分配：fmt.Sprintf 内部会创建缓冲区并进行多次内存分配
  3. 格式解析：需要解析格式字符串中的占位符

你的基准测试结果清晰地展示了差异：

  • fmt.Sprintf: 428.4 ns/op, 128 B/op, 6 allocs/op
  • 字符串拼接: 59.12 ns/op, 0 B/op, 0 allocs/op

性能差异的原因示例：

// fmt.Sprintf 内部大致相当于：
func inefficientSprintf(format string, args ...interface{}) string {
    // 1. 解析格式字符串
    // 2. 对每个参数进行类型反射
    // 3. 创建临时缓冲区
    // 4. 多次内存分配和复制
    return formattedString
}

// 字符串拼接直接编译为：
func efficientConcat(name string) string {
    // 编译器优化为单个字符串构建
    return "One for " + name + ", one for me."
}

何时使用哪种方法：

// 简单拼接 - 使用字符串拼接
func greet(name string) string {
    return "Hello, " + name + "!"
}

// 复杂格式化 - 使用 fmt.Sprintf
func formatUser(user User) string {
    return fmt.Sprintf("User{ID: %d, Name: %s, Age: %d}", 
        user.ID, user.Name, user.Age)
}

// 性能关键路径 - 使用 strings.Builder
func buildLargeString(items []string) string {
    var builder strings.Builder
    builder.Grow(estimateSize) // 预分配内存
    for _, item := range items {
        builder.WriteString(item)
    }
    return builder.String()
}

基准测试验证：

func BenchmarkSprintf(b *testing.B) {
    name := "Alice"
    for i := 0; i < b.N; i++ {
        _ = fmt.Sprintf("One for %v, one for me.", name)
    }
}

func BenchmarkConcat(b *testing.B) {
    name := "Alice"
    for i := 0; i < b.N; i++ {
        _ = "One for " + name + ", one for me."
    }
}

func BenchmarkBuilder(b *testing.B) {
    name := "Alice"
    for i := 0; i < b.N; i++ {
        var builder strings.Builder
        builder.WriteString("One for ")
        builder.WriteString(name)
        builder.WriteString(", one for me.")
        _ = builder.String()
    }
}

对于简单的字符串拼接，确实应该避免使用 fmt.Sprintf。这不是微不足道的微优化，在循环或高频调用的代码路径中，性能差异会累积成显著的开销。只有在需要复杂格式化（多种类型、宽度控制、精度控制等）时才使用 fmt.Sprintf。

回到顶部