Author: tridge Date: 2005-08-30 00:36:12 +0000 (Tue, 30 Aug 2005) New Revision: 9769
WebSVN: http://websvn.samba.org/cgi-bin/viewcvs.cgi?view=rev&root=samba&rev=9769 Log: [EMAIL PROTECTED]: tridge | 2005-08-30 10:40:19 +1000 added a tdb optimisation that speeds up non-indexed ldb by a large margin (often 10x or more). I'd be interested in any comments on the safety of this optimisation. See the comment in the code for an explanation. Modified: branches/SAMBA_4_0/ branches/SAMBA_4_0/source/lib/tdb/common/tdb.c Changeset: Property changes on: branches/SAMBA_4_0 ___________________________________________________________________ Name: svk:merge - a953eb74-4aff-0310-a63c-855d20285ebb:/local/samba4:11080 + a953eb74-4aff-0310-a63c-855d20285ebb:/local/samba4:11592 Modified: branches/SAMBA_4_0/source/lib/tdb/common/tdb.c =================================================================== --- branches/SAMBA_4_0/source/lib/tdb/common/tdb.c 2005-08-30 00:26:44 UTC (rev 9768) +++ branches/SAMBA_4_0/source/lib/tdb/common/tdb.c 2005-08-30 00:36:12 UTC (rev 9769) @@ -1250,6 +1250,43 @@ /* Lock each chain from the start one. */ for (; tlock->hash < tdb->header.hash_size; tlock->hash++) { + + /* this is an optimisation for the common case where + the hash chain is empty, which is particularly + common for the use of tdb with ldb, where large + hashes are used. In that case we spend most of our + time in tdb_brlock(), locking empty hash chains. + + To avoid this, we do an unlocked pre-check to see + if the hash chain is empty before starting to look + inside it. If it is empty then we can avoid that + hash chain. If it isn't empty then we can't believe + the value we get back, as we read it without a + lock, so instead we get the lock and re-fetch the + value below. + + Notice that not doing this optimisation on the + first hash chain is critical. We must guarantee + that we have done at least one fcntl lock at the + start of a search to guarantee that memory is + coherent on SMP systems. If records are added by + others during the search then thats OK, and we + could possibly miss those with this trick, but we + could miss them anyway without this trick, so the + semantics don't change. + + With a non-indexed ldb search this trick gains us a + factor of more than 10 in speed on a linux 2.6.x + system. + */ + if (!tlock->off && tlock->hash != 0) { + u32 off; + if (ofs_read(tdb, TDB_HASH_TOP(tlock->hash), &off) == 0 && + off == 0) { + continue; + } + } + if (tdb_lock(tdb, tlock->hash, F_WRLCK) == -1) return -1;
