编译时性能成本

Question

在我看来，这两种方法中，第一种存在与

string concat

和

toCharArray

相关的性能问题。但我被告知这两个操作都发生在编译时，因此没有性能开销。

如果这是真的，那么为什么编译时操作不是性能开销？

private final static char[] DigitTens = {
     ("0000000000"+ "1111111111"+"2222222222"+"3333333333"+"4444444444" //
     +"5555555555"+"6666666666"+"7777777777"+"8888888888"+"9999999999")
      .toCharArray();             
};

VS：

private final static char[] DigitTens = {
    '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
    '1', '1', '1', '1', '1', '1', '1', '1', '1', '1',
    '2', '2', '2', '2', '2', '2', '2', '2', '2', '2',
    '3', '3', '3', '3', '3', '3', '3', '3', '3', '3',
    '4', '4', '4', '4', '4', '4', '4', '4', '4', '4',
    '5', '5', '5', '5', '5', '5', '5', '5', '5', '5',
    '6', '6', '6', '6', '6', '6', '6', '6', '6', '6',
    '7', '7', '7', '7', '7', '7', '7', '7', '7', '7',
    '8', '8', '8', '8', '8', '8', '8', '8', '8', '8',
    '9', '9', '9', '9', '9', '9', '9', '9', '9', '9',
};

Answer 1

带有

+

的字符串连接表达式是一个 常量表达式，并在编译时解析（JLS §15.28）。但是，

toCharArray()

调用是在运行时执行的。总的来说，您的第一个片段相当于：

private final static char[] DigitTens;

static {
    DigitTens = "0000000000111111111122222222223333333333444444444455555555556666666666777777777788888888889999999999"
            .toCharArray();
}

你的第二个片段相当于：

private final static char[] DigitTens;

static {
    DigitTens = new char[100];
    DigitTens[0] = '0';
    DigitTens[1] = '0';
    ...
    DigitTens[99] = '9';
}

（您可以通过

javap -c

在字节码中自己看到这一点）

最终，不要担心这里的性能；您可能不会看到差异。选择您认为更清晰且更易于管理的内容。通常，编译代码所需的时间是无关紧要的，因为编译阶段实际上应该只发生一次，之后您将处理生成的包含字节码的

.class

文件。

我还要指出，在这种特定情况下，

DigitTens[i]

只是

i / 10

，假设

i

在 0-99 范围内（含）。

Answer 2

回答这个问题

如果这是真的，那么为什么编译时操作不是性能 管理费用？

他们是。但它们只在每次程序创建时出现一次，并且在程序运行期间绝不会出现。

我认为我不必担心编译器性能（除了查看构建的整体结构之外）。我会为了清晰而编码，并且不会担心性能，除非它成为问题。这同样适用于运行时性能。

Answer 3

“编译时”性能开销会影响开发人员，并可能在他/她的整个生命周期中花费一毫秒的时间。

运行时性能开销可能每秒发生 x 次，成本相当高。

对于您的具体示例，第二种方法稍微更有效（可以说以清晰度为代价），因为它消除了在运行时调用 toCharArray 的需要。