变量存储与冗余算术的区别

短答案是，这几乎不会有任何区别。即使有任何形式的差异，您的代码旁边是绘制一条线，例如。即使使用原生代码实现高度优化的 Bresenham 算法绘制中断线路，与加减相比，成本仍然非常高昂。即使仅仅是函数调用的成本，也可能会让它相形见绌。

对于第二个实体，我必须计算两次低差异和高差异。对于第一个实体，我必须将它们存储在内存中，并且每个差异都要访问两次。

这并不一定是这样的。变量不一定以表达式不存储存储的方式。它们可以直接映射到寄存器。同样，避免使用变量不一定可以“避免内存”。表达式也将计算并存储在寄存器中，无论您是否将中间结果明确分配给变量。

因此，从内存的角度来看，您代码的这两个版本都需要使用寄存器来存储计算的中间结果。

当您只涉及简单变量时，记忆化不一定具有这种类型的内存开销，主要是因为类型直接映射到寄存器而不需要堆栈溢出。当您开始提前计算整个数组/表时，如果记忆化意味着需要更多 DRAM 访问，则有时进行额外的计算会更快（在这种情况下，内存开销可能会超过节省的费用）。但是，像数字这样的简单 POD 类型变量没有 DRAM 开销，它们直接映射到寄存器。换句话说，它们经常是免费的：无论您是否将表达式的结果分配给本地变量，编译器都会生成相同的机器代码 - 需要相同数量的寄存器。

将数据类型映射到 GP 寄存器的本地变量最好被视为仅存在于高级编码领域。当 JIT 或解释器将您的代码编译成计算机可以理解的形式时，它们将消失并转换为寄存器，不管您是否创建了这些变量。

最终问题可能是，如果存在任何差异，则多余计算是否可以被消除。只需最简单的优化器即可发现在完全相同的语句中两次写入 mid - diff 的计算只需要计算一次。如果到达 IR 指令选择和寄存器分配阶段时，我会感到惊讶，如果没有被优化掉，那么它可能会成为一个惊喜。

但即使它被证明是一个惊喜，并且 Lua 解释器太低效，无法识别完全冗余的计算并进行执行，那么你也有代码旁边渲染一条线（这涉及循环光栅化）。相对而言，即使存在冗余，这几乎是免费的。在这里，不值得为这些小事而大汗淋漓，这是从一个对削减时钟周期着迷的人那里得出的结论。