时间戳

首页 > 解决方案 > 具有静态内容的地图定义上的 Golang 行为（编译时构造？）

go - 具有静态内容的地图定义上的 Golang 行为（编译时构造？）

问题描述

让我们采用以下 Golang 表达式：

type MyStruct struct {
  foo int,
  bar map[string]MyInterface 
}
type MyInterface interface { /* ... */ }
func firstFunc() { /* ...*/ }
func secondFunc() { /* ...*/ }

具有以下构建器功能：

func NewMyStruct() *MyStruct {
  // Building a map made of only static content, known at compile time
  // Assigning it to a local variable
  m := map[string]MyInterface {
    "first": firstFunc,
    "second": secondFunc,
  }
  /* ... */
  return &MyStruct{
    bar: m, // Copying the map into the struct field
    /* ... */
  }
}

我遇到了这段代码，并决定尝试在内存管理和/或执行时间方面对其进行优化。来自 C++ 世界，我习惯了“静态分配与动态分配”的困境以及constexpr. 我试图在 Golang 中实现相同的目标：避免在语言允许的范围内过于频繁地构造/分配数据结构。

问题 1：在NewMyStruct()中，临时地图是否在每次调用时有效地分配给构造/分配？m

问题2：编译器能否检测到临时地图是由静态内容构成的，并且一次性构造出来？

我的另一个解决方案是使用全局定义的映射并MyStruct使用指针从实例中引用它。

标签： gomemory-management

解决方案

正如沃尔克所说，这几乎可以肯定是过早的优化。但是，如果您已经发现这会在您的程序中花费大量时间并且只是在寻找选项，则此 Playground 链接显示了一种在程序启动时构建地图并共享它的方法。本质只是：

return &MyStruct{bar: sharedMap, /*...*/}

此时需要创建共享地图。如果无法进行简单的静态初始化，请使用init functionsync.Once ，或在第一次调用函数时添加 a以仅构造一次映射New。

推荐阅读