golang循环初始比剩余慢

Question

我是 golang 的新手，在做这个 poc 时，我注意到在运行 for 循环时有一个奇怪的行为。

    package main;

    import (

        "log"

        "strings"

        "time"

    )

    type data struct {

        elapseTime int64

        data string

    }

    func main(){

        for i := 0 ; i < 10; i++{

            c := make(chan data);

            go removeDuplicates("I love oranges LALALA I LOVE APPLES LALALA XD", c);

            log.Printf("%v", <- c);

        }

    }

    func removeDuplicates(value string , c chan data){

        start := time.Now();

        var d = data{};

        var r string;

        value = strings.ToLower(value);

        var m = make(map[string]string);

        splitVals := strings.Split(value, " ");

        for _, element := range splitVals {

            if _, ok := m[element]; ok == false {

                m[element] = element;

            }

        }

        for k, _ := range m {

            r = r + k + " ";

        }

        d.data = strings.TrimRight(r, "");

        d.elapseTime = time.Since(start).Nanoseconds();

        c <- d;

    }

实际上，我想要实现的是删除一个简单字符串的重复项，并将这些信息连同所花费的时间一起打印出来。一个循环通过 go routine 运行 10 次，等待通过通道的响应。

2019/05/24 00:55:49 {18060 i love oranges lalala apples xd }

2019/05/24 00:55:49 {28930 love oranges lalala apples xd i }

2019/05/24 00:55:49 {10393 i love oranges lalala apples xd }

2019/05/24 00:55:49 {1609 oranges lalala apples xd i love }

2019/05/24 00:55:49 {1877 i love oranges lalala apples xd }

2019/05/24 00:55:49 {1352 i love oranges lalala apples xd }

2019/05/24 00:55:49 {1708 i love oranges lalala apples xd }

2019/05/24 00:55:49 {1268 apples xd i love oranges lalala }

2019/05/24 00:55:49 {1736 oranges lalala apples xd i love }

2019/05/24 00:55:49 {1037 i love oranges lalala apples xd }

这是我所看到的：循环的前几次打印（无论是单循环还是 100x 循环都无关紧要）将比循环的其余部分慢得多。这是有原因的吗？（执行时间以纳秒为单位）

编辑：删除开关部分，因为人们对这个问题感到困惑。

Answer 1

并发不是并行。通道的这种特殊使用结果与仅从 返回值非常相似removeDuplicates，只是两个 goroutine 需要协调它们对通道的使用会产生额外的开销。具体来说：循环的每次迭代都有自己的通道，每个通道只能容纳一个元素。在所有语句都已执行之前，循环无法继续下一次迭代，包括对该语句的调用log.Printf阻塞，直到从通道接收到值。removeDuplicates检测到实时时间已经过去了多少，而不是在解决问题上花费了多少时间。这是评论说它首先不是一个很好的基准的众多原因之一。推测：在循环的前几次迭代中，goroutine 可能removeDuplicates会初始化start，然后将执行时间交给主 goroutine。然后 main goroutine 立即检查 mutex on c，发现它还不能做任何事情，并返回给调度程序，所有这些检查和上下文切换增加了数千纳秒（关心这通常是微基准测试的味道）到goroutineremoveDuplicates的实时执行。main在几次迭代之后，某些东西（也许是 Go 运行时）发现了在返回之前永远无法取得进展的事实removeDuplicates，并且避免了上下文切换。我知道此时您对解释比建议更感兴趣，但如果我不指出比较 Go 和 Java 的基准已经存在，我会觉得很不负责任。即使您想自己编写，我也建议使用类似的方法：根据需要完成的任务定义基准程序，然后使用每种语言（或框架）中可用的最佳工具来完成工作具有良好的性能。