> 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
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)
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).
PS: Just to ward off the inevitable flood of suggestions, yes I'm
aware of oprofile, cachegrind, gprof etc.