场景: 我想快速阅读一个大文本文件(例如 lorem.txt，在下面的示例中有 4.5 millon 行)。我在下面的代码中尝试了三种不同的方式。

1. 非并发顺序处理
2. channel 和协程
3. WaitGroup 和协程

伪基准: 这是我在下面运行时得到的典型输出；下面的输出是快速而肮脏的时间增量，而不是完整的分析/基准测试/测试。

sequential:     43.541828091 secs 4714074 lines
queued channel: 80.986544385 secs 4714074 lines
wait group:     260.200473751 secs 4712266 lines

问题: 为什么顺序循环比下面的其他两种方法更快？我错过了什么吗？

更新 我在一个更大的文本文件上运行示例代码(参见场景)。我还为每个示例“重置”了记录器，以防万一不这样做会在示例函数之间产生一些复杂的内存问题。也正如其他人所指出的，我的电脑是双核的，这可能是我的代码存在的许多问题之一。感谢所有反馈/回答。

package main

import (
    "bufio"
    "bytes"
    "fmt"
    "log"
    "os"
    "sync"
    "time"
)

var (
    textFile = "lorem.txt"
    buf      bytes.Buffer
    l        = log.New(&buf, "logger: ", log.Lshortfile)
    wg       sync.WaitGroup
    delta1   float64
    delta2   float64
    delta3   float64
    cnt1     = 0
    cnt2     = 0
    cnt3     = 0
)

func main() {

    // Wait Group Example
    exampleWaitGroup()

    // Queued Channel Example
    exampleQueuedChannel()

    // Sequential Loop Example
    exampleSequentialLoop()

    benchmarks := fmt.Sprintf("sequential:\t%v secs %v lines\nqueued channel:\t%v secs %v lines\nwait group:\t%v secs %v lines\n",
        delta1, cnt1,
        delta2, cnt2,
        delta3, cnt3,
    )

    fmt.Println(benchmarks)

}

func exampleSequentialLoop() {

    buf.Reset()
    l = log.New(&buf, "logger: ", log.Lshortfile)

    start := time.Now()

    file1, err := os.Open(textFile)
    if err != nil {
        log.Fatal(err)
    }

    defer file1.Close()

    scanner := bufio.NewScanner(file1)

    for scanner.Scan() {
        cnt1++
        l.Println(scanner.Text())
    }

    end := time.Now()
    delta1 = end.Sub(start).Seconds()

}

func exampleQueuedChannel() {

    buf.Reset()
    l = log.New(&buf, "logger: ", log.Lshortfile)

    start := time.Now()
    queue := make(chan string)
    done := make(chan bool)

    go processQueue(queue, done)

    file2, err := os.Open(textFile)
    if err != nil {
        log.Fatal(err)
    }

    defer file2.Close()

    scanner := bufio.NewScanner(file2)

    for scanner.Scan() {
        queue <- scanner.Text()
    }

    end := time.Now()
    delta2 = end.Sub(start).Seconds()
}

func exampleWaitGroup() {

    buf.Reset()
    l = log.New(&buf, "logger: ", log.Lshortfile)

    start := time.Now()

    file3, err := os.Open(textFile)
    if err != nil {
        log.Fatal(err)
    }

    defer file3.Close()

    scanner := bufio.NewScanner(file3)

    for scanner.Scan() {
        wg.Add(1)
        go func(line string) {
            defer wg.Done()
            l.Println(line)
            cnt3++
        }(scanner.Text())
    }

    wg.Wait()

    end := time.Now()
    delta3 = end.Sub(start).Seconds()

}

func processQueue(queue chan string, done chan bool) {
    for line := range queue {
        l.Println(line)
        cnt2++
    }
    done <- true
}

最佳答案

在 exampleQueuedChannel 中，您没有并行执行任何操作。是的，您已经启动了另一个 goroutine，但是没有并行处理。原因是 queue 是一个无缓冲的 channel 。当您写入未缓冲的 chan 时，写入器会阻塞，直到有人读取它为止。所以基本上你在写的时候阻塞，然后调度器必须让 goroutine 进入休眠状态，然后去唤醒读 goroutine。然后那个人睡着了，作家又醒了。所以你在两个 goroutine 之间来回折腾，调度器正在做繁重的工作。
如果你想在这里获得更好的性能，请使用缓冲 channel 。如果您想要更高的性能，请在每个 channel 消息中增加多个项目^{(有关 channel 性能影响的详细技术解释，请阅读 this)}。。 p>

在 exampleWaitGroup 中，您将为每一行启动一个新的 goroutine。虽然启动新的 goroutines 并不昂贵，但它也不是免费的，而且对调度程序来说也是更多的工作。 defer is also not free .还有你的记录器 uses a mutex ，所以如果你的两个 goroutines 试图同时记录，一个将被置于休眠状态，然后更多调度程序工作。

您可以通过launching your code under a profiler自行调查这些问题。 ，并调查瓶颈所在。

关于go - 为什么顺序循环比 Go 中的并发方法运行得更快？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/51006592/