tdb2: use direct access functions when creating recovery blob
We don't need to copy into a buffer to examine the old data: in the
common case, it's mmaped already. It's made a bit trickier because
the tdb_access_read() function uses the current I/O methods, so we
need to restore that temporarily.
The difference was in the noise, however (the sync no-doubt
dominates).
Before:
$ time ./growtdb-bench 250000 10 > /dev/null && ls -l /tmp/growtdb.tdb && time ./tdbtorture -s 0 && ls -l torture.tdb && ./speed --transaction
2000000
real 0m45.021s
user 0m16.261s
sys 0m2.432s
-rw------- 1 rusty rusty
364469344 2011-04-27 22:55 /tmp/growtdb.tdb
testing with 3 processes, 5000 loops, seed=0
OK
real 1m10.144s
user 0m0.480s
sys 0m0.460s
-rw------- 1 rusty rusty 391992 2011-04-27 22:56 torture.tdb
Adding
2000000 records: 863 ns (
110601144 bytes)
Finding
2000000 records: 565 ns (
110601144 bytes)
Missing
2000000 records: 383 ns (
110601144 bytes)
Traversing
2000000 records: 409 ns (
110601144 bytes)
Deleting
2000000 records: 676 ns (
225354680 bytes)
Re-adding
2000000 records: 784 ns (
225354680 bytes)
Appending
2000000 records: 1191 ns (
247890168 bytes)
Churning
2000000 records: 2166 ns (
423133432 bytes)
After:
real 0m47.141s
user 0m16.073s
sys 0m2.460s
-rw------- 1 rusty rusty
364469344 2011-04-27 22:58 /tmp/growtdb.tdb
testing with 3 processes, 5000 loops, seed=0
OK
real 1m4.207s
user 0m0.416s
sys 0m0.504s
-rw------- 1 rusty rusty 313576 2011-04-27 22:59 torture.tdb
Adding
2000000 records: 874 ns (
110601144 bytes)
Finding
2000000 records: 565 ns (
110601144 bytes)
Missing
2000000 records: 393 ns (
110601144 bytes)
Traversing
2000000 records: 404 ns (
110601144 bytes)
Deleting
2000000 records: 684 ns (
225354680 bytes)
Re-adding
2000000 records: 792 ns (
225354680 bytes)
Appending
2000000 records: 1212 ns (
247890168 bytes)
Churning
2000000 records: 2191 ns (
423133432 bytes)