Julia全局变量导致代码运行速度降低一个数量级问题咨询

Julia的高性能完全建立在类型稳定的编译优化基础上：只有当编译器能提前确定代码中所有变量的固定类型时，才能生成和C/Fortran效率相当的原生机器码。

全局变量天生是类型不稳定的：全局作用域的变量可以在程序运行的任意时刻被重新赋值为任意类型的值，编译器在编译函数时，完全无法对全局变量的类型做确定性假设。这就导致所有引用全局变量的位置，都必须在运行时动态执行类型检查、方法派发，这类单次开销极低的操作，在你这个10万次模拟、多层循环嵌套的热路径上会被累计放大，最终产生10倍的性能差距。

你用精简小例子没能复现这个差异，通常是两个原因：一是小例子执行路径太短，动态开销累计量不足，性能差在毫秒级很难被观测到；二是部分极简场景下编译器会做跨过程的常量传播，意外优化掉了全局变量带来的开销，无法复现最坏情况下的性能损失。

两个版本的性能差还有一个容易被忽略的细节：全局作用域下的DEBUG = false，编译器无法确认它会不会在函数运行过程中被其他代码修改为true，因此不会做死代码消除，所有和DEBUG相关的条件判断、打印分支逻辑都会被完整保留，每次循环都要执行一次判断；而局部作用域下的DEBUG = false会被编译器直接识别为编译期常量，所有DEBUG分支的代码会被直接剔除，进一步减少了无效指令的执行量。

• 优先使用局部变量：如果变量仅在单个函数或局部作用域内使用，直接定义在对应作用域内部是最优选择，编译器可以自动完成全量类型推断和优化，不需要额外做任何处理。
• 全局固定配置必须加const修饰：如果确实需要在全局作用域定义不会变更类型的配置项（比如你代码里的囚犯总数、尝试次数上限、调试开关），声明为常量即可让编译器获得确定的类型信息，优化后的性能和局部变量版本没有可感知的差异，修改方式如下：

const DEBUG = false
const PRISONERS = 100
const ATTEMPTS = 50

注意Julia的const仅限制变量绑定的类型不能变更，给const变量赋同类型的新值只会抛出警告不会阻断程序运行，只有赋值为不同类型的值才会报错，完全适配绝大多数配置场景的需求。

• 避免在热路径直接访问可变全局变量：如果需要使用全局可变的状态，不要在核心循环里直接读写裸全局变量，可以选择两种优化方案：一是把可变状态封装到自定义结构体中，作为参数传入需要使用的函数；二是用Ref包装全局可变值，访问时明确标注值的类型，消除动态派发开销。
• 用内置工具排查类型不稳定问题：遇到不明原因的性能下降时，可以对热点函数调用@code_warntype 函数名()，输出内容中标记为红色的Any类型位置，就是类型不稳定的性能热点，这类热点通常由未加const的全局变量、返回类型不确定的函数导致，针对性调整即可。

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