ldb speed

tridge at samba.org tridge at samba.org
Mon Oct 30 23:41:59 GMT 2006


 > Ok, let's get back to the original question, do you want me do work on
 > making struct ldb_dn private ?

That would be great, thanks! A quick grep indicates that all we will
need is a couple of extra ldb_dn_*() helper functions.

btw, it might work out OK to explode the DN 'on demand'. So we'd have
the char* format in the struct ldb_dn, but also have the broken out
components, and only form the broken out components when a function is
called that needs them. It could also have a flags field that
indicates if the DN has been validated and if it has been

To make this work we probably need to do the following:

 - rename ldb_dn_explode() to ldb_dn_construct() or similar name,
   meaning "take a char* form and construct an opaque struct
   ldb_dn". The name ldb_dn_explode() implies that we will actually
   explode it, when in many cases we don't have to.

 - have a completely separate call ldb_dn_validate() that does the
   validation checks. This would only be called in places where a DN
   has come from an external input, not when the DN has come from
   something internal.

While doing this work, please keep an eye on the performance with
LOCAL-DBSPEED. Profiling is good too, although most profiling tools
are pretty pathetic unfortunately.

The way I've been doing profiling for this work is like this:

 - select a target function (say ldb_dn_explode()). 

 - rename it to XX_ldb_db_explode(). 

 - create a new function like this:

   struct ldb_dn *ldb_dn_explode(void *mem_ctx, const char *dn)
	talloc_free(XX_ldb_dn_explode(mem_ctx, dn));
	return XX_ldb_dn_explode(mem_ctx, dn);

 - rerun LOCAL-DBSPEED and see how much the 'usec per op'
   changes. That is a pretty good estimate of the cost of the
   ldb_dn_explode() function. (yes, for the pedants in the audience,
   I'm aware of the cache and related affects this ignores).

Cheers, Tridge

PS: Just to ward off the inevitable flood of suggestions, yes I'm
aware of oprofile, cachegrind, gprof etc.

More information about the samba-technical mailing list