Go's Once Type的效率测量

时间:2018-11-19 13:58:34

标签: performance go synchronization mutex

我有一段代码只想运行一次即可进行初始化。 到目前为止,我一直在使用sync.Mutex结合if子句来测试它是否已经运行。后来,我在同一个同步包中遇到了Once类型及其DO()函数。

实现如下https://golang.org/src/sync/once.go

func (o *Once) Do(f func()) {
    if atomic.LoadUint32(&o.done) == 1 {
        return
    }
    // Slow-path.
    o.m.Lock()
    defer o.m.Unlock()
    if o.done == 0 {
        defer atomic.StoreUint32(&o.done, 1)
        f()
    }
}

看代码,基本上和我以前使用过的一样。互斥体与if子句结合。但是,添加的函数调用对我来说似乎效率很低。我做了一些测试,并尝试了各种版本:

func test1() {
    o.Do(func() {
        // Do smth
    })
    wg.Done()
}

func test2() {
    m.Lock()
    if !b {
        func() {
            // Do smth
        }()
    }
    b = true
    m.Unlock()
    wg.Done()
}

func test3() {
    if !b {
        m.Lock()
        if !b {
            func() {
                // Do smth
            }()
            b = true
        }
        m.Unlock()
    }
    wg.Done()
}

我通过运行以下代码测试了所有版本:

    wg.Add(10000)
    start = time.Now()
    for i := 0; i < 10000; i++ {
        go testX()
    }
    wg.Wait()
    end = time.Now()

    fmt.Printf("elapsed: %v\n", end.Sub(start).Nanoseconds())

具有以下结果:

elapsed: 8002700 //test1
elapsed: 5961600 //test2
elapsed: 5646700 //test3

使用一次类型甚至值得吗?它很方便,但是性能比总是序列化所有例程的test2还要差。

此外,为什么他们在if子句中使用atomic int?无论如何,存储都发生在锁内。

编辑:转到运动场链接:https://play.golang.org/p/qlMxPYop7kS注意:由于时间在运动场中固定,因此不会显示结果。

1 个答案:

答案 0 :(得分:3)

那不是您应该测试代码性能的方式。您应该使用Go的内置测试框架(testing软件包和go test命令)。有关详细信息,请参见Order of the code and performance

让我们创建可测试的代码:

func f() {
    // Code that must only be run once
}

var testOnce = &sync.Once{}

func DoWithOnce() {
    testOnce.Do(f)
}

var (
    mu = &sync.Mutex{}
    b  bool
)

func DoWithMutex() {
    mu.Lock()
    if !b {
        f()
        b = true
    }
    mu.Unlock()
}

让我们使用testing包编写适当的测试/基准测试代码:

func BenchmarkOnce(b *testing.B) {
    for i := 0; i < b.N; i++ {
        DoWithOnce()
    }
}

func BenchmarkMutex(b *testing.B) {
    for i := 0; i < b.N; i++ {
        DoWithMutex()
    }
}

我们可以使用以下代码运行基准测试

go test -bench .

这是基准测试结果:

BenchmarkOnce-4         200000000                6.30 ns/op
BenchmarkMutex-4        100000000               20.0 ns/op
PASS

如您所见,使用sync.Once()的速度几乎是使用sync.Mutex的4倍。为什么?因为sync.Once()具有“优化”的短路径,所以仅使用原子加载来检查任务是否已在以前被调用,如果是,则不使用互斥锁。第一次调用Once.Do()时,“慢速”路径可能仅使用一次。尽管如果您有许多并发的goroutine试图调用DoWithOnce(),慢速路径可能会多次到达,但从长远来看,once.Do()仅需要使用原子负载。

并行测试(来自多个goroutine)

是的,以上基准测试代码仅使用单个goroutine进行测试。但是,使用多个并发的goroutine只会使互斥锁的情况变得更糟,因为它总是必须获取一个互斥锁才能检查sync.Once仅使用原子加载时是否要调用该任务。

尽管如此,让我们对其进行基准测试。

以下是使用并行测试的基准测试代码:

func BenchmarkOnceParallel(b *testing.B) {
    b.RunParallel(func(pb *testing.PB) {
        for pb.Next() {
            DoWithOnce()
        }
    })
}

func BenchmarkMutexParallel(b *testing.B) {
    b.RunParallel(func(pb *testing.PB) {
        for pb.Next() {
            DoWithMutex()
        }
    })
}

我的机器上有4个内核,所以我要使用这4个内核:

go test -bench Parallel -cpu=4

(您可以省略-cpu标志,在这种情况下,它默认为GOMAXPROCS -可用内核数。)

结果如下:

BenchmarkOnceParallel-4         500000000                3.04 ns/op
BenchmarkMutexParallel-4        20000000                93.7 ns/op

当“并发性增加”时,结果开始变得不可比拟,而得到sync.Once的支持(在上述测试中,速度提高了30倍)。

我们可能会进一步增加使用testing.B.SetPralleism()创建的goroutine的数量,但是当我将其设置为100时,我会得到类似的结果(这意味着使用了400个goroutines来调用基准代码)。