Le 05/07/16 à 02:16, robert geiger a écrit : > Using a simple test to evaluate BTree vs. ConcurrentSlipListMap, creating the > BTree as follows: > > BTree<String, byte[]> btree = new BTreeFactory().createInMemoryBTree( "test", > new StringSerializer(StringComparator.INSTANCE), new > ByteArraySerializer(ByteArrayComparator.INSTANCE)); > > And using insert() to add 5M keys with a small (16 byte) value and iterating > over a browse cursor to scan gave: > > Run test: BTree > create tree > Start load > time to load 5000000 values 8330094154 (8.33009408 secs) > time to scan 5000000 values 233224649 (0.233224656 secs) > > Run test: skip list > create skip list > Start load > time to load 5000000 values 4582309650 (4.582309888 secs) > time to scan 5000000 values 113716936 (0.113716936 secs) > > This seems disappointing as expected better performance from the BTree, am I > misusing or misconfiguring the map for this test case?
In Memory BTrees are based on a MVCC Btree implementation, which copy pages from top to bottom when instering elements in the B-tree. When you have many elements, like in your test, you can expect 6 pages to be copied (at least) for every insertion (5 000 000 log 16, where each page can contain 16 elements). That is enough to explain the huge difference you can see. The whole idea is to keep the possibility to work with an ancient revision, if needed.
