使用static变量进行性能优化的判定标准是什么？

先看你给出的OpenGL渲染代码：

void renderScene(void)
{
    //Clear all pixels
    glClear(GL_COLOR_BUFFER_BIT);
    // Question : Declaring posAttrib as a static variable is good? or bad?
    GLint posAttrib = glGetAttribLocation(programID, "vtxPosition");


    glVertexAttribPointer(posAttrib, 3, GL_FLOAT, GL_FALSE, 0, ((void*)(0)));
    glEnableVertexAttribArray(posAttrib);
    glDrawArrays(GL_POINTS, 0, 3);

    //Double buffer
    glutSwapBuffers();
}

renderScene会被频繁调用，把posAttrib改成static确实能避免每次调用都执行glGetAttribLocation——这个函数的开销不算极大，但高频调用下累积起来的消耗是可观的，而且programID和"vtxPosition"在程序运行中大概率不会变化，所以这个场景下用static是合理的。

以下是通用的判定标准：

核心判定标准 #

1. 确认重复操作的真实优化价值 #

要优化的操作必须是高频重复执行，且单次执行有不可忽略的开销（比如系统调用、复杂计算、大内存分配/拷贝）。像glGetAttribLocation这类查询型API，或是需要反复初始化大对象的场景，才值得考虑static。如果只是简单的变量赋值（比如int a = 0;），编译器会自动优化，完全没必要用static。

2. 确认缓存值的稳定性 #

static变量的初始化只会执行一次，后续调用会保留上次的结果。因此必须确保：你要缓存的值不会在函数多次调用之间发生变化。比如你的例子里，只要programID对应的着色器程序没有重新链接，vtxPosition的属性位置就不会变，用static缓存是安全的。但如果这个值可能在后续调用中改变（比如动态切换着色器程序），用static就会导致逻辑错误。

3. 权衡static的副作用是否可接受 #

static变量的常见问题：

• 线程安全风险：如果函数被多线程调用，static变量的初始化和访问可能引发竞态条件（加同步锁又会抵消性能收益）。
• 维护成本提升：其他开发者看到static变量时，需要额外确认缓存逻辑、值的稳定性，增加了代码理解成本。
• 长期内存占用：static变量会一直占用内存直到程序结束，若缓存的是大对象，需评估内存开销是否值得。

只有当性能收益远大于这些副作用时，才适合用static做优化。

4. 优先选择更优雅的替代方案 #

很多时候static不是最优解：

• 比如你的OpenGL场景，更规范的做法是在着色器程序链接完成后，一次性查询所有属性位置并存在全局变量/类成员变量中，既避免了高频调用开销，又没有static的副作用。
• 局部场景下，也可以把计算逻辑提到函数外部只执行一次，再将结果传入函数。

总结决策流程 #

用static做性能优化的判断步骤：

1. 确认高频执行的操作确实有明显开销；
2. 确认要缓存的值在函数多次调用中不会变化；
3. 评估static的副作用（线程安全、维护成本等）是否在可接受范围内；
4. 检查是否存在更优雅的非static替代方案。

只有同时满足前三点，且没有更好的替代方案时，才适合用static来做性能优化。

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