测试FatVariableLengthGammaTransaction的性能

分配一个比较大的二维数组,然后在一个transaction中遍历这个二维数组,测试当单个transaction读写很多对象的时候的性能瓶颈。

测试代码如下:
static AtomicBlock block = GlobalStmInstance.getGlobalStmInstance().newTransactionFactoryBuilder().setIsolationLevel(IsolationLevel.Serializable).setSpeculative(false).newAtomicBlock();
static final IntRef[][] grids = new IntRef[2500][2500];
public static void loop() {

block.execute(new AtomicVoidClosure() {
    public void execute(Transaction tx) throws Exception {
        for (int i = 0; i != 2500; ++i) {
            for (int j = 0; j != 2500; ++j) {
                grids[i][j].set(tx, 1);
            }
        }
    }
});

}

public static void main(String[] args) {
System.out.println("begin");

for (int i = 0; i != 2500; ++i) {
    for (int j = 0; j != 2500; ++j) {
        grids[i][j] = StmUtils.newIntRef();
    }
}
  for(int count=0;count!=10;count++)
    loop();
System.out.println("end");

}

测试结果:

20110930profile1

第一个方法,GammaObjectPool,是为了防止老是new对象,所以把废弃不用的对象组成了一个Object Pool。

第二个,就是openForRead的时候需要频繁在hash表中查。

prepare虽说看起来耗时不长,但是实际上,平均算下来,每次提交事务的时候,prepare总计耗时约300ms左右(需要遍历600万个对象)。

另外这个图隐去了对hashCode计算所带来的消耗。是因为已经重复运行5次,而hashCode在计算过一次之后就被cache住了。所以带来的影响不显著。但是如果所要遍历的对象是频繁new出来的,System.identityHashCode()方法的消耗还是比较大的。

此博客中的热门博文

在windows下使用llvm+clang

少写代码,多读别人写的代码

tensorflow distributed runtime初窥