对于字符串哈希，方向看起来与我早期工作中的https://go-review.googlesource.com/c/go/+/148177/4非常相似，当时在发送审查时并不受欢迎。
新的作用域似乎更广泛，可以根据需要生成特定长度的 Package 器以推导它们，但思路基本相同。
我很乐意沿着这个方向重新设计算法生成，通过将上面的CL(链接)中原始意图(并考虑到josh的改进)延续到一个新的CL中，添加更多类型并根据需要生成特定长度的 Package 器以消除重复项。
使用基于寄存器的调用约定，额外的调用所需的成本也会更低，因此可能是更好的二进制大小和速度权衡。
关于一般方法的讨论：在其他类型的算法中生成代码，而不是直接调用具有额外长度参数的类型数组算法，是否会比闭包更好？

关于更大的问题，我想让@randall77发表意见。
在其他类型的算法中，使用直接调用具有额外长度参数的类型数组算法而不是闭包来生成代码会更好吗？
当然了。我链接的CL确实缺少这一点以及更多内容，比如在检查任何内容之前先检查所有字符串长度的优化，以及直接调用bytealg.Equal来比较内容。

在runtime中使用辅助函数处理常见类型的数组似乎没问题。我认为CL 148177中的反对意见是有两个更改，分别是执行前一句话和手动内联strhash。将其拆分成两个单独的CL会更好，这样我们可以分别看到每个更改的效果。
对于将直接分配给runtime._type.equal或runtime.maptype.hasher的函数，我们仍然需要使用闭包。
你可能已经注意到了这一点，但请注意，这些优化的一个可能的复杂情况是，对于哈希值，任何优化后的哈希算法仍需与runtime.typehash完全匹配。请参阅#37716。

算法通常被认为是编译器/运行时中可以做得更好的部分。我将再次关注它们(将此问题分配给我),除了一般的清理和重构之外，还将研究以下内容：

• 引入处理哈希数组(以及多个结构字段)的函数(此问题)
• 用memhash替换strhash的使用(对于数组算法来说更容易，已经为equals完成)
• 将 Package 简单类型的类型解引用，例如[1]string和struct{ string },仅保留用于哈希和equals的字段类型。这避免了为单元素数组构建或调用额外的算法函数。单元素数组可能会在创建用于初始化切片值的后备数组时出现。

我将我的早期https://golang.org/cl/148177重构以考虑这里的其他改进，并将解引用部分拆分出来。
在上述内容之后，我认为我们可以看到表格上剩下的内容，并可能还可以考虑作为通用概念在运行时/编译器中使用的masked memequals:#41774

这个问题没有被遗忘，并且已经重新列入我的待办事项列表，以便在go1.18中解决。正在努力更新和同步现有的CLs到HEAD。