JMH难题:StringBuilder与StringBand

igr*_*igr 3 java benchmarking jmh

我很难理解这个基准测试的进展情况.我想测量我的样本类的StringBand工作方式StringBuilder.这个想法StringBand是连接字符串,而toString()不是连接字符串append().

来源

这是StringBand源 - 剥离基准:

public class StringBandSimple {

private String[] array;
private int index;
private int length;

public StringBandSimple(int initialCapacity) {
    array = new String[initialCapacity];
}

public StringBandSimple append(String s) {
    if (s == null) {
        s = StringPool.NULL;
    }
    if (index >= array.length) {
        //expandCapacity();
    }
    array[index++] = s;
    length += s.length();
    return this;
}

public String toString() {
    if (index == 0) {
        return StringPool.EMPTY;
    }

    char[] destination = new char[length];
    int start = 0;
    for (int i = 0; i < index; i++) {
        String s = array[i];
        int len = s.length();
        //char[] chars = UnsafeUtil.getChars(s);
        //System.arraycopy(chars, 0, destination, start, len);
        s.getChars(0, len, destination, start);
        start += len;
    }
    return new String(destination);
}
}
Run Code Online (Sandbox Code Playgroud)

此代码使用:UnsafeUtil.getChars()实际获取Stringchar []而不复制,请参阅此处的代码.我们也可以使用getChars()和它仍然相同.

这是JMH测试:

@State
public class StringBandBenchmark {

String string1;
String string2;

@Setup
public void prepare() {
    int len = 20;
    string1 = RandomStringUtil.randomAlphaNumeric(len);
    string2 = RandomStringUtil.randomAlphaNumeric(len);
}

@GenerateMicroBenchmark
public String stringBuilder2() {
    return new StringBuilder(string1).append(string2).toString();
}

@GenerateMicroBenchmark
public String stringBand2() {
    return new StringBandSimple(2).append(string1).append(string2).toString();
}

}
Run Code Online (Sandbox Code Playgroud)

分析

这是我对添加两个字符串20个字符时发生的事情的理解.

StringBuilder的

  • new char[20+16] 创建(36个字符)
  • arraycopy被称为复制20个string1字符StringBuilder
  • 在第二次追加之前,StringBuilder扩大容量,因为40> 36
  • 因此,new char[36*2+2]创造了
  • arraycopy 20个字符到新的缓冲区
  • arraycopy 20个字符附加秒 string2
  • 最后,toString()回归new String(buffer, 0, 40)

StringBand

  • new String[2] 被建造
  • 两者都只是将字符串保留在内部缓冲区中,直到toString()被调用
  • length 增加两次
  • new char[40] 已创建(结果字符串的总长度)
  • arraycopy20个第一个字符串字符(UnsafeUtil提供字符串的实际char[]缓冲区)
  • arraycopy 20秒的字符串字符
  • 最后,回归 new String(buffer, 0, 40)

期望

随着StringBand我们:

  • 少一点arraycopy- 这样做的目的是什么
  • 减少分配规模:new String[]new char[]两个new char[]
  • 加上我们没有像StringBuilder方法那样的很多检查(对于大小等)

所以我希望它StringBand至少可以起作用StringBuilder,如果不是更快的话.

基准测试结果

我在2013年中期在MacBookPro上运行基准测试.使用JMH v0.2和Java 1.7b45

命令:

java -jar build/libs/microbenchmarks.jar .*StringBand.* -wi 2 -i 10 -f 2 -t 2
Run Code Online (Sandbox Code Playgroud)

预热迭代次数(2)很好,因为我可以看到第二次迭代达到相同的性能.

Benchmark                                    Mode Thr     Count  Sec         Mean   Mean error    Units
j.b.s.StringBandBenchmark.stringBand2       thrpt   2        20    1    37806.993      174.637   ops/ms
j.b.s.StringBandBenchmark.stringBuilder2    thrpt   2        20    1    76507.744      582.131   ops/ms
Run Code Online (Sandbox Code Playgroud)

结果说StringBuilder是两倍快.当我将线程数增加到16或BlackHole在代码中使用显式s时,也会发生同样的情况.

为什么?

Ale*_*lev 21

好吧,像往常一样,"猫头鹰不是他们看起来的样子".通过快速检查Java代码来推理代码性能变得奇怪.通过查看字节码来推理感觉是一样的.生成的代码反汇编应该更多地阐明这一点,即使有一些小的情况下,程序集太高,无法解释这种现象.

这是因为平台在各个层面都大量优化了代码.这是你应该看的提示.在i5 2.0 GHz,Linux x86_64,JDK 7u40上运行您的基准测试.

基线:

Benchmark                                    Mode Thr     Count  Sec         Mean   Mean error    Units
j.b.s.StringBandBenchmark.stringBand2       thrpt   2        20    1    25800.465      297.737   ops/ms
j.b.s.StringBandBenchmark.stringBuilder2    thrpt   2        20    1    55552.936      876.021   ops/ms
Run Code Online (Sandbox Code Playgroud)

是的,令人惊讶.现在,看看这个.我的袖子里什么都没有,除了......

-XX:-OptimizeStringConcat:

Benchmark                                    Mode Thr     Count  Sec         Mean   Mean error    Units
j.b.s.StringBandBenchmark.stringBand2       thrpt   2        20    1    25727.363      207.979   ops/ms
j.b.s.StringBandBenchmark.stringBuilder2    thrpt   2        20    1    17233.953      219.510   ops/ms
Run Code Online (Sandbox Code Playgroud)

禁止VM进行字符串优化会产生"预期"结果,如原始分析中所述.众所周知,HotSpot具有围绕StringBuilders的优化,有效地识别通常的习语,new StringBuilder().append(...).append(...).toString()并为语句生成更有效的代码.

拆解并弄清楚应用的字符串优化究竟发生了什么,留给感兴趣的读者练习:)