php小编香蕉为您介绍指针操作和CPU/内存使用情况。在编程中，指针操作是一种强大的工具，可以直接访问和修改内存中的数据。通过了解指针操作，您可以更好地控制和优化代码的性能。另外，了解CPU和内存的使用情况对于优化程序也非常重要。通过监测和分析CPU和内存的使用情况，您可以找出潜在的性能问题，并采取相应的措施来提升程序的运行效率。在本文中，我们将为您详细介绍指针操作和CPU/内存使用情况的相关知识，帮助您更好地理解和应用它们。
问题内容
我在工作中与一位同事讨论将指针传递给函数和/或返回指针是否更有效。
我整理了一些基准函数来测试执行此操作的不同方法。这些函数基本上接受一个变量，对其进行转换并将其传回。我们有 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 正在发生变化，因此我们在一个版本中证明的内容不一定在另一个版本中也成立。
