Java枚举的性能? [英] Performance of Java Enums?

查看:112
本文介绍了Java枚举的性能?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在实施一个双人游戏,这个游戏将在紧密的循环中运行,几十遍,然后才是最重要的。

I am implementing a 2-player game that will be run in a tight loop literally hundreds of thousands of times, being then performance paramount.

我的代码实际上是如下所示:

My code actually looks something like this:

public class Table {
    private final int WHITE_PLAYER = +1;
    private final int BLACK_PLAYER = -1;

    private final int currentPlayer;
    private final int otherPlayer;

    ...
}

我想知道我是否将获得任何表现,我会选择替换

I was wondering if I would get any performance hit would I choose to replace

private final int WHITE_PLAYER = +1;
private final int BLACK_PLAYER = -1;

定义为

public enum Players {
    WhitePlayer,
    BlackPlayer
}

我的想法是,枚举只是句法糖超过整数常量,并瞥见了为测试枚举生成的字节码,以及调用它的代码,似乎表明使用它们实际上与使用静态方法调用相同,但是对于在首次运行时设置的某些枚举基础架构也是如此。

I had the idea that enums were just syntactic sugar over integer constants, and taking a glaze look over the bytecode generated for a test enum, as well as the code calling it, seems to indicate that using them is indeed the same as making a static method call but for some enum infrastructure that is set up when it's first run.

我的假设是使用枚举确实是一样的作为静态常量正确,或者我在这里缺少某些东西?

Is my assumption that it is indeed the same to use enums as static constants correct or am I missing something here?

推荐答案

在微型基准测试中,是的,检查整数常量相等将是比检查枚举恒定平等更快。

In a micro-benchmark, yes, checking integer constant equality will be faster than checking enum constant equality.

然而,在一个真正的应用程序中,更不用说一个游戏,这将是完全不相关的。 AWT子系统(或任何其他GUI工具包)中发生的事情将这些微观性能考虑因素降低许多数量级。

However, in a real application, let alone a game, this will be totally irrelevant. The things that are happening in the AWT subsystem (or any other GUI toolkit) dwarf these micro-performance considerations by many orders of magnitude.

编辑

请稍等一点。

枚举比较如下:

aload_0
getstatic
if_acmpne

一个小整数的整数比较如下所示:

An integer comparison for a small integer goes like this:

iload_0
iconst_1
if_icmpne

显然,第一个比第二个更多的工作,虽然差别很大

Obviously, the first is more work than the second, although the difference is quite small.

运行以下测试用例:

class Test {

    static final int ONE = 1;
    static final int TWO = 2;

    enum TestEnum {ONE, TWO}

    public static void main(String[] args) {
        testEnum();
        testInteger();
        time("enum", new Runnable() {
            public void run() {
                testEnum();

            }
        });
        time("integer", new Runnable() {
            public void run() {
                testInteger();
            }
        });
    }

    private static void testEnum() {
        TestEnum value = TestEnum.ONE;
        for (int i = 0; i < 1000000000; i++) {
            if (value == TestEnum.TWO) {
                System.err.println("impossible");
            }
        }
    }

    private static void testInteger() {
        int value = ONE;
        for (int i = 0; i < 1000000000; i++) {
            if (value == TWO) {
                System.err.println("impossible");
            }
        }
    }

    private static void time(String name, Runnable runnable) {
        long startTime = System.currentTimeMillis();
        runnable.run();
        System.err.println(name + ": " + (System.currentTimeMillis() - startTime) + " ms");
    }
}

,你会发现枚举比较慢整数比较,在我的机器上大约1.5%。

and you will find that the enum comparison is slower that the integer comparison, on my machine by around 1.5%.

我所说的是,这种差异在真正的应用程序中并不重要(过早优化是一切邪恶)。我在专业的基础上处理性能问题(见我的个人资料),我从来没有看到可以追溯到这样的热点。

All I was saying is that this difference will not matter in a real application ("Premature optimization is the root of all evil"). I deal with performance problems on a professional basis (see my profile) and I have never seen a hot spot that could be traced to something like this.

这篇关于Java枚举的性能?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆