Raspberry Pi上C#的foreach循环为何比for循环慢10倍？

核心结论 #

不需要始终优先使用for循环替代foreach，你遇到的性能差异属于特定软硬件环境下的特殊情况，绝大多数普通开发场景下二者性能差距可以忽略，优先选择可读性更高的写法即可。

性能差异原因解释 #

• 首先明确foreach的运行逻辑：遍历List<T>这类实现了IEnumerable<T>的集合时，foreach会自动创建枚举器实例，调用MoveNext()方法遍历、通过Current属性取值。在x86/x64架构的Windows环境下，.NET运行时的JIT编译器对枚举器遍历做了深度优化，绝大多数场景下foreach性能和for基本持平。
• 你测试使用的树莓派属于ARM架构，旧版本.NET（.NET 6及更早版本）对ARM平台的JIT优化完善度远低于x86平台，枚举器遍历的优化没有落地，才会出现数倍的性能差距。如果升级到.NET 7及以上版本，这个性能差会被大幅缩小。
• 注意你给出的两段测试代码并不完全对等：foreach会自动适配集合的实际长度，而你写的for循环硬编码了1000次的遍历上限，仅在集合长度刚好为1000时运行正确，实际生产环境不建议写死循环边界。

更推荐的优化方案 #

你当前代码的性能瓶颈本质上不是循环方式，而是字符串不可变带来的高频内存分配：每次+=操作都会创建新的字符串对象，会产生大量临时内存和GC压力，不管用什么循环性能都有很大提升空间。
更高效的写法有两种：

1. 使用StringBuilder拼接字符串：

private static string ComposeRegs(List<list_of_bytes> registers)
{
    StringBuilder sb = new StringBuilder();
    foreach (var register in registers)
    {
        sb.Append(Convert.ToString(register.RegisterValue));
        sb.Append(',');
    }
    return sb.ToString();
}

2. 直接使用.NET内置的string.Join方法，官方已经做了极致性能优化，一行代码即可实现需求：

private static string ComposeRegs(List<list_of_bytes> registers)
{
    return string.Join(',', registers.Select(r => r.RegisterValue));
}

选型建议 #

• 普通业务开发场景：优先用foreach，可读性更高、不容易出现数组越界等边界错误，性能差异完全可以忽略。
• 性能敏感的热点路径，且运行在ARM平台、使用旧版本.NET的场景：可以考虑用for循环代替foreach做性能优化，优化前建议先做性能测试确认收益。

内容的提问来源于stack exchange，提问作者Usman Mehmood