LeetCode“两数之和”：Golang切片赋值性能差异分析

在LeetCode“两数之和”问题中，笔者尝试了两种不同的Golang代码实现，并观察到其运行时间的显著差异。

代码示例一：

<code class="go">func twosum(nums []int, target int) []int {
    m := make(map[int]int)
    l := make([]int, 2, 2)
    for firstindex, firstvalue := range nums{
        difference := target - firstvalue
        if lastindex, ok := m[difference]; ok{
            l[0] = firstindex
            l[1] = lastindex
            return l
        }
        m[firstvalue] = firstindex
    }
    return nil
}</code>

代码示例二：

立即学习“go语言免费学习笔记（深入）”；

<code class="go">func twoSum(nums []int, target int) []int {
    m := map[int]int{}
    for firstIndex, firstValue := range nums{
        difference := target - firstValue
        if lastIndex, ok := m[difference]; ok{
            return []int{firstIndex, lastIndex}
        }
        m[firstValue] = firstIndex
    }
    return nil
}</code>

性能差异及原因探究

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

测试结果显示，代码示例二的运行时间明显长于代码示例一。然而，仔细对比两段代码，其逻辑和切片处理方式并无本质区别，切片的容量和长度均为2。

经过分析，这种性能差异并非源于代码本身的缺陷或切片赋值方式，而是以下几个因素共同作用的结果：

1. 测试用例的随机性： LeetCode平台每次提交都会使用不同的测试数据集，导致运行时间存在波动。

2. 平台负载和环境因素： 服务器负载、网络状况等因素都会影响代码的执行效率。

3. 多次提交的影响： 即使使用相同的代码，多次提交也可能产生不同的结果。

因此，代码示例二运行时间较长，很可能是由于LeetCode平台的测试环境和测试数据造成的，与代码中切片赋值的细微差别关系不大。 这提醒我们，在进行性能测试时，需要考虑测试环境的稳定性和测试数据的代表性，避免得出片面的结论。