对C#在unity编译环境下foreach关键字GC的测试

曾经有一段时间，个人因为foreach会产生GC而始终不敢放开了使用foreach，直至前段时间看到了一篇知乎上发布的文章

作为Unity3D的脚本而言，c#中for是否真的比foreach效率更高？ - 王剑飞的回答 - 知乎
https://www.zhihu.com/question/30334270/answer/49858731

因此，我赶紧写了个脚本测试一下foreach的GC情况

用foreach遍历List

脚本：

public class TestGC : MonoBehaviour {

    List<GameObject> intlist = new List<GameObject>();

    private void Start()
    {
        for (int i = 0; i < 1000; ++i) intlist.Add(gameObject);

        foreach (GameObject obj in intlist) Debug.Log(obj);

    }

    private void Update()
    {
        Debug.Break();
        //Debug.Log特别耗费GC，因此用这个方便定位
        foreach (GameObject obj in intlist) Debug.Log(obj);
    }
}

获得结果

可以看到，调用了1000次Debug.Log耗时454ms，已经足够显眼了

emmm……居然没有创建迭代器……

用foreach遍历Dictionary

因为上一个实验中实际上并未显示GC的情况，因此这里需要换个容器进行

    Dictionary<int, GameObject> dict1;

    private void Awake()
    {
        dict1 = new Dictionary<int, GameObject>();
        for (int i =0;i<50; ++i)
        {
            dict1.Add(i, gameObject);
        }
    }
    
    void Start () {
        foreach (KeyValuePair<int, GameObject> pair in dict1)
        {
            Debug.Log(pair.Value.name);
        }
    }
	
	void Update () {
        Debug.Break();
    }

运行结果

可以看到，foreach展开后的GetEnumera()、MoveNext、Dispose等函数就都显现出来了
foreach本质上就是对正常程序员使用迭代器过程的简化，并不是什么很特别的关键字

调用了GetEnumera函数，GC是32B

然后……可以下定论了？

这里需要修改一下代码继续测试

用foreach遍历多次Dictionary

将start中的遍历复制三份

    void Start () {
        foreach (KeyValuePair<int, GameObject> pair in dict1)
        {
            Debug.Log(pair.Value.name);
        }
        foreach (KeyValuePair<int, GameObject> pair in dict1)
        {
            Debug.Log(pair.Value.name);
        }
        foreach (KeyValuePair<float, GameObject> pair in dict2)
        {
            Debug.Log(pair.Value.name);
        }
    }

运行结果：

可以看到，Calls数量增加了，然而GC Alloc没有发生变化

到这里，我也怀疑过这个GC是指每一次Call进行的内存分配
然而，把之前的测试结果拿出来，对比一下Debug.Log栏目的GC Alloc


就可以断定，这个的确是总的GC变化
也就是，使用foreach循环3次和1次的GC Alloc量是一样的

但这也引出一个问题：一开始的32B内存是在什么情况下分配的？

对影响foreach进行GC Alloc的因素进行测试

大多人之前不敢用foreach，原因也主要在于foreach会莫名地产生GC，拖慢性能
因此，还需要用一些平时做项目中时常出现的情况对其进行测试

闭包对其的影响的测试

以下是对Start的修改（将一个foreach包裹在for中）

    void Start () {
        for(int i = 0; i < 10; ++i)
        {
            foreach (KeyValuePair<int, GameObject> pair in dict1)
            {
                Debug.Log(pair.Value.name);
            }
            foreach (KeyValuePair<float, GameObject> pair in dict2)
            {
                Debug.Log(pair.Value.name);
            }
        }
        foreach (KeyValuePair<int, GameObject> pair in dict1)
        {
            Debug.Log(pair.Value.name);
        }
        foreach (KeyValuePair<int, GameObject> pair in dict1)
        {
            Debug.Log(pair.Value.name);
        }
    }

结果：

可以看到，无影响

不同脚本调用对其的影响
原本应该尝试测试一下在不同函数调用对GC的影响，但直接测试在不同脚本调用的情况可以省去这个麻烦
因此，我将脚本复制了一份

运行结果：

无影响，calls也自然而然地变成了两倍
既然在不同脚本调用不会生成GC，自然在不同函数调用也一样不会生成GC
当然。由此也可以大致猜到分配的32BGC的用途了。

不同迭代器类型对其的影响
修改一下脚本代码

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class TestGC : MonoBehaviour {

    Dictionary<int, GameObject> dict1;
    Dictionary<float, GameObject> dict2;
    private void Awake()
    {
        dict1 = new Dictionary<int, GameObject>();
        dict2 = new Dictionary<float, GameObject>();
        for (int i =0;i<50; ++i)
        {
            dict1.Add(i, gameObject);
            dict2.Add(i, gameObject);
        }
    }
    
    void Start () {
        for(int i = 0; i < 10; ++i)
        {
            foreach (KeyValuePair<int, GameObject> pair in dict1)
            {
                Debug.Log(pair.Value.name);
            }
            foreach (KeyValuePair<float, GameObject> pair in dict2)
            {
                Debug.Log(pair.Value.name);
            }
        }
        foreach (KeyValuePair<int, GameObject> pair in dict1)
        {
            Debug.Log(pair.Value.name);
        }
        foreach (KeyValuePair<float, GameObject> pair in dict2)
        {
            Debug.Log(pair.Value.name);
        }
    }
	
	//测试一下游戏时间对其的影响
	void Update () {

        foreach (KeyValuePair<int, GameObject> pair in dict1)
        {
            Debug.Log(pair.Value.name);
        }
        Debug.Break();
    }
}

运行结果：

原本32B的GC变成了64B
可以说，GetEnumera的单例特性是实锤了

而后，以下是脚本中update函数里foreach的GC情况

0B

结论

1. 对List的遍历不会使用到迭代器
2. unity中调用C#的foreach，本质上是对调用迭代器进行遍历的一系列过程的简化
3. dictionary中的GetEnumera使用了单例模式的思想，如果不存在相关迭代器则创建，如果存在则将之修改一下拿去继续用
4. unity的工程师并没有傻到隔了三四年都不去修复foreach的bug
5. 由第三和第四条结论可以推出，System.Collections中的结构在迭代这方面基本不会随意产生GC
6. 由第二、第五条结论可推出，如果哪天使用foreach迭代时出现了大量GC，请检查一下进行遍历的类是否出有问题

当然，因为个人也是初学者，以上部分结论可信度大概在五成左右，如果这次测试有不完善的地方，请指出
谢谢阅读