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)
Showing
Please register or sign in to comment