【问题标题】:Is there a performance impact for using code blocks in Java?在 Java 中使用代码块是否会影响性能?
【发布时间】:2012-04-08 20:00:12
【问题描述】:

我开始使用 Java 中的 OpenGL,我遇到了一种情况,我需要在许多 glBegin() 和 glEnd() 调用之间放置大量代码,并且希望代码是自动格式化,以便一眼就能看出哪个代码属于哪个 glBegin/glEnd。

为此,我一直在使用匿名代码块,如下所示:

glBegin(GL_QUADS);
{
   glVertex2f(100, 100);
   glVertex2f(100+200, 100);
   glVertex2f(100+200, 100+200);
   glVertex2f(100, 100+200);
}
glEnd();

我的问题是:以这种方式使用代码块是否有任何性能问题,即使非常轻微?还是和程序编译后完全不使用代码块一样?

【问题讨论】:

  • 如果您担心性能,您应该真正使用现代 OpenGL 技术。使用 VBO (OpenGL 1.5+) 的性能优势将比您在立即模式渲染周围优化所有内容的尝试高出几个数量级。
  • 需要考虑的一点是,阅读您的代码的任何人都可能对为什么这些调用在不同的范围内感到困惑。
  • 其实我经常使用这样的积木。这与范围有点关系,但更多的是与可读性有关。好吧,我发现它更容易阅读,我不了解我的同事:-)。

标签: java opengl lwjgl


【解决方案1】:

使用这样的块应该没有成本。块是用于范围界定的语言的句法特征,并且没有关联的运行时功能。查看 JVM 执行的编译字节码,无法判断函数的作用域规则是什么,因此 JVM 应该在有和没有块的情况下提供相同的性能。

如果您认为它更易于阅读,请随意执行此操作。事实上,这几乎总是你的首要任务,除非你有理由怀疑。

希望这会有所帮助!

【讨论】:

  • 实际上我很确定没有什么难的方法可以做到这一点,因为块的存在绝对不会影响 java 程序的语义或更改任何规则(在 java 中这是非法的对于在块中声明的变量来隐藏局部变量,所以我们不能有两个不同的变量 x 例如)
  • @Voo- 如果您在多个范围内声明了相同的变量,您可能会对类文件中的符号执行某些操作,但总的来说我同意。
  • 你会怎么做?我也不确定,所以我检查了一下,{int x; { char x;} } 给出了编译错误。所以我们不能在内部块中隐藏局部变量,我认为这是唯一可以改变允许这种事情的语言的语义(或至少是代码)的东西。
  • @Voo- 是的,我忘记了你不能在 Java 中做到这一点。在那种情况下,我很确定这是不可能的。 :-)
  • 是的,我也必须尝试一下 - 实际上我也很确定它会起作用,并希望将其作为额外作用域产生一些影响的案例来展示;)
【解决方案2】:

对 glVertex 的无数次调用对性能的影响比其他任何事情都大得多。这应该是你真正关心的问题。查看顶点数组和顶点缓冲区对象以获得真正的性能提升。您的代码也会看起来更好。

【讨论】:

    【解决方案3】:

    如果您不打算将变量声明为块的本地变量,则根本不要使用本地块。这样做除了很可能导致必须阅读和维护您的代码的人(包括您自己)感到困惑之外,您一无所获。

    本地块对于在方法内声明短期对象很有用,这些对象仅在块的持续时间内保留在范围内。即便如此,也无法保证他们会在方法结束之前收集到垃圾。

    使用本地块作为性能优化没有实际意义,您最好对应用程序进行分析并调整被证明很慢的部分,而不是执行诸如此类最终会使代码更难阅读和维护。

    使用本地块来提高可读性,这是值得商榷的,但它可能会为在块内执行的代码的范围问题打开一大堆蠕虫,可能会产生一些非常难以发现的错误。

    为了便于阅读,为什么不在 glBegin()glEnd() 之前和之后放置几个位置合适的 cmets?

    【讨论】:

    • 你写过一些OpenGL代码吗? (如果没有,您可能不知道 old openGL 代码的通常结构)虽然我大体上同意,但当我编写 c++ OpenGL 代码时,我也缩进了 glBegin/End 并且看到了很多类似的代码.它只是有助于突出结构 - 否则它会变得非常混乱,而 cmets 也无济于事。同样在 Java 中,通过引入额外的本地范围(afaics)来改变代码的语义是不可能的,所以我认为它不会混淆任何人。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2017-07-15
    • 1970-01-01
    • 1970-01-01
    • 2013-03-09
    • 1970-01-01
    • 2013-06-14
    • 1970-01-01
    相关资源
    最近更新 更多