C语言中数组索引是否比三元运算符执行速度更快

实话说，现代编译场景下你提的这两种写法根本不存在谁天然更快的区别，最终执行效率完全由编译器的优化结果决定，和表面写法的关系极小。

先搞懂两种写法的本质 #

你对比的两种写法，核心都是实现“N大于10就返回14，否则返回8”的逻辑：

• 数组索引写法：(const int[]){8, 14}[N > 10]
  利用C语言布尔判断结果只会是0（假）、1（真）的特性，把这个0/1值当数组下标，直接从存了两个常量的数组里取值。
• 三元运算符写法：N > 10 ? 14 : 8
  最常规的条件取值分支写法。

实际编译产出的代码差异 #

• 零优化场景（比如-O0，基本不会用于生产环境的编译模式）：
  两种写法的生成代码确实有细微差别：数组写法会额外执行栈上临时const数组的初始化、把布尔判断结果转成整数做地址偏移取数的操作，指令数量略多；三元写法在零优化下会直接生成硬跳转分支。但这点操作的耗时连现代CPU的一个时钟周期都不到，完全感知不到差异。
• 常规优化场景（也就是日常写代码常用的-O1、-O2等级别）：
  编译器会直接把两种写法优化成完全相同的机器码。毕竟编译器很容易识别“从两个编译期常量里靠布尔判断选值”的模式，不管你用哪种写法，最终都会转成无分支的条件选择指令（比如x86平台的cmov、ARM平台的csel）——既不会保留栈上临时数组的冗余操作，也不会生成容易触发分支预测失败的硬跳转。

别被网上的“无分支性能优势”误导 #

很多人觉得数组写法是无分支实现，天生比带分支的三元运算符快，但实际上三元写法在开优化后根本就不会生成硬分支，和数组写法的优化结果没有任何区别。如果N的取值能被编译器提前推导为常量，两种写法连判断步骤都会被直接删掉，直接替换成对应的固定返回值。
只有当数组元素不是编译期常量、甚至把数组放到动态堆内存里的时候，数组访问的开销才会真的比三元写法高。你举的例子是栈上的const常量数组，根本触发不了这种场景。

真要较真做性能测试的话，把两种写法各跑一亿次循环取值，相同编译参数下的耗时差基本都是CPU计时的随机误差，根本不会出现某一种写法稳定比另一种快的结果。

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