掌握指针操作和CPU/内存利用情况

在评估指针传递和函数返回值的效率时，基准测试显示令人惊讶的结果。第四个测试（传入指针，不返回）被认为最有效，但实际表现却最差，花费时间和内存最多。这种现象表明，指针传递和返回的效率并非直观可预测，需要更深入的理解。

我在工作中与一位同事讨论将指针传递给函数和/或返回指针是否更有效。

我整理了一些基准函数来测试执行此操作的不同方法。这些函数基本上接受一个变量，对其进行转换并将其传回。我们有 4 种不同的方法：

1. 正常传入变量，为转换结果创建一个新变量并传回它的副本
2. 正常传入变量，为转换结果创建一个新变量，并传回内存地址
3. 传入一个指向变量的指针，为转换结果创建一个新变量并传回该变量的副本
4. 传入一个指向变量的指针，对指针的值进行转换，无需传回任何内容。

package main

import (
    "fmt"
    "testing"
)

type mystruct struct {
    mystring string
}

func acceptparamreturnvariable(s mystruct) mystruct {
    ns := mystruct{
        fmt.sprintf("i'm quoting this: \"%s\"", s.mystring),
    }
    return ns
}

func acceptparamreturnpointer(s mystruct) *mystruct {
    ns := mystruct{
        fmt.sprintf("i'm quoting this: \"%s\"", s.mystring),
    }
    return &ns
}

func acceptpointerparamreturnvariable(s *mystruct) mystruct {
    ns := mystruct{
        fmt.sprintf("i'm quoting this: \"%s\"", s.mystring),
    }
    return ns
}

func acceptpointerparamnoreturn(s *mystruct) {
    s.mystring = fmt.sprintf("i'm quoting this: \"%s\"", s.mystring)
}

func benchmarknormalparamreturnvariable(b *testing.b) {
    s := mystruct{
        mystring: "hello world",
    }
    var ns mystruct
    for i := 0; i < b.n; i++ {
        ns = acceptparamreturnvariable(s)
    }
    _ = ns
}

func benchmarknormalparamreturnpointer(b *testing.b) {
    s := mystruct{
        mystring: "hello world",
    }
    var ns *mystruct
    for i := 0; i < b.n; i++ {
        ns = acceptparamreturnpointer(s)
    }
    _ = ns
}

func benchmarkpointerparamreturnvariable(b *testing.b) {
    s := mystruct{
        mystring: "hello world",
    }
    var ns mystruct
    for i := 0; i < b.n; i++ {
        ns = acceptpointerparamreturnvariable(&s)
    }
    _ = ns
}

func benchmarkpointerparamnoreturn(b *testing.b) {
    s := mystruct{
        mystring: "hello world",
    }
    for i := 0; i < b.n; i++ {
        acceptpointerparamnoreturn(&s)
    }
    _ = s
}

我发现结果相当令人惊讶。

$ go test -run=XXXX -bench=. -benchmem
goos: darwin
goarch: amd64
pkg: XXXX
cpu: Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz
BenchmarkNormalParamReturnVariable-16           10538138               103.3 ns/op            48 B/op          2 allocs/op
BenchmarkNormalParamReturnPointer-16             9526380               201.2 ns/op            64 B/op          3 allocs/op
BenchmarkPointerParamReturnVariable-16           7542066               147.0 ns/op            48 B/op          2 allocs/op
BenchmarkPointerParamNoReturn-16                   45897            119265 ns/op          924351 B/op          5 allocs/op

在运行这个之前，我认为最有效的方法是第四个测试，因为在被调用的函数范围内没有创建新变量，并且只传递内存地址，但是，似乎第四个是效率最低的，花费最多的时间，并且使用最多的内存。

有人可以向我解释这一点，或者为我提供一些很好的阅读链接来解释这一点吗？

正确答案

您所做的基准测试并不能回答您提出的问题。事实证明，微基准测试极其困难——不仅在 go 世界中，而且在一般情况下也是如此。

回到效率问题。通常，将指针传递给函数不会转义到堆。通常，从函数返回的指针确实会逃逸到堆中。通常是这里的关键词。您无法真正说出编译器何时在堆栈上以及何时在堆上分配某些内容。这不是一个小问题。可以在此处找到非常好的简短解释。

但是如果您需要知道，可以询问。您可以从简单地打印编译器做出的优化决策开始。您可以通过将 m 标志传递给 go 工具compile 来完成此操作。

go build -gcflags -m=1

如果传递大于 1 的整数，则会得到更详细的输出。如果它没有给您优化程序所需的答案，请尝试分析。它远远超出了内存分析的范围。

一般来说，在日常工作中不要为幼稚的优化决策而烦恼。不要太执着于“通常......”的说法，因为在现实世界中，你永远不知道。始终首先以正确性优化为目标。然后仅在您确实需要并且证明您需要它时才进行性能优化。不要猜测，不要相信。另外，请记住，go 正在发生变化，因此我们在一个版本中证明的内容不一定在另一个版本中也成立。

以上就是《掌握指针操作和CPU/内存利用情况》的详细内容，更多关于的资料请关注golang学习网公众号！