abartlet at samba.org
Mon Oct 30 02:57:19 GMT 2006
On Mon, 2006-10-30 at 14:16 +1100, tridge at samba.org wrote:
> As we've discussed previously, ldb is currently way too slow. The
> LOCAL-DBSPEED test is a simple way to demonstrate this - it tests both
> ldb and tdb for the example of a sidmap style database (something like
> what winbind_idmap.tdb currently holds).
> In LOCAL-DBSPEED compiled with optimisation, each ldb search takes
> about 45 usec on my test machine. The equivalent tdb fetch takes about
> 8 usec. It's even worse if you factor out the system overhead of
> locking. With locking disabled a tdb fetch takes about 3 usec, whereas
> a ldb search takes around 40 usec.
> As I understand it, the change to the ldb_dn structure format was
> needed to allow us to correctly handle some of the semantics of
> ldap. Could we support all those semantics with a char* format? I
> think we could.
How do you intend to determine if a component needs to be case or format
canonicalized without parsing it?
Remember, we can't just upper or lower case the whole string. Parts may
be case sensitive, while other parts may not be.
> There is a lot more room for optimisation in other parts of ldb, but
> fixing the current struct ldb_dn is the main thing. I'd suggest we try
> the following strategy to start with.
> 1) make 'struct ldb_dn' a private structure to ldb_dn.c. Keep it in
> the API for now, but make it an opaque structure as far as the
> rest of our code is concerned. That will involve adding some
> public routines to extract properties of a 'struct ldb_dn' to
> allow us to fix up the (very few!) external bits of code that
> currently look inside a struct ldb_dn
> 2) once we've made it an internal only structure, we can start
> changing its shape. It could become as simple as a 'char*'
> internally, or could retain some flags, or even a broken out array
> that gets created on demand.
> 3) make sure we differentiate between callers where input needs to be
> validated and callers where it does not need validation.
These seem reasonable API steps, but I am not clear you can avoid the
need for a encode/decode pass.
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc. http://redhat.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20061030/49d19b43/attachment.bin
More information about the samba-technical