Java:我应该如何/应该使用多个 IF 语句优化方法？

Question

这个问题不像主题中那样普遍。这里我有 Builder 模式以方便用户使用，还有一个带有多个 IF 的方法。但是，每个 IF 语句都是对象的 non-final 字段之一的条件。在所考虑的方法体内也没有对这些字段的赋值操作，因为类的 API 没有提供 setter 。示例:

public class MyFormatter {
    public static class Builder {
        private final boolean notOptional;  // don't mind this one, just the Builder pattern
        private boolean optionalA, optionalB, optionalC;  // these would matter further
        private Builder optionalA() { optionalA = true; return this; }
        private Builder optionalB() { optionalB = true; return this; }
        private Builder optionalC() { optionalC = true; return this; }

        public Builder(boolean notOptional) {
            this.notOptional = notOptional;
        }

        public MyFormatter build() {
            MyFormatter formatter = new MyFormatter(notOptional);
            formatter.optionalA = optionalA;
            formatter.optionalB = optionalB;
            formatter.optionalC = optionalC;

            return formatter;
        }
    }

    private final boolean notOptional;
    private boolean optionalA, optionalB, optionalC;  // Not final

    private MyFormatter(boolean notOptional) {
        this.notOptional = notOptional;
    }

    protected String publish(String msg) {
        StringBuilder sb = new StringBuilder();

        // Here we go: a lot of IFs, though conditions "effectively never" change
        if (optionalA) {
            sb.append("something");
        }

        if (optionalB) {
            sb.append("something else");
        }

        if (optionalC) {
            sb.append("and something else");
        }

        return sb.toString();
    }
}

好的，现在的问题是 JIT 编译器可以做多少来优化这段代码，以及我是否可以做些什么来优化它(一些惰性初始化等)。

附注(更难的问题)想象一下这个代码被翻译成 JavaScript(由 GWT)，即没有 JVM 会参与执行/优化这个方法。在这种情况下，程序员可以做些什么来提高性能？

Answer 1

It is absolutely crucial for dev to see the real-time dynamics and each millisecond matter a lot.

就是这样。除非您的开发人员每秒可以读取数千条消息，否则您没问题。成本

    if (optionalA) {
        sb.append("something");
    }

由两部分组成。

• 条件分支和追加。预测错误的分支需要 10-20 个周期，即在 3 GHz CPU 上最多 20/3 纳秒。正确预测的分支基本上是免费的，并且由于 boolean 值是常量并且代码是热的，您可以假设。
• 根据"something"的长度，追加的代价可能更大，但没有给出细节，所以没有什么可以优化的。

我认为 JIT 不会在这里找到可以优化的东西。您可以调整 StringBuilder 的大小以获得一些 yield 。

总而言之，是过早的优化。

Imagine this code being translated in JavaScript (by GWT)

现代浏览器与 Java 一样具有高级 JIT。由于 Javascript 是弱类型的，它不能那么快，但已经非常接近了。

在优化之前进行测量，这样您就不会把时间花在 CPU 不在的地方。