RE: An optimization for another day (and developer)

["Howard Chu" <hyc@highlandsun.com>]

> -----Original Message-----
> From: owner-openldap-devel@OpenLDAP.org
> [mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Pierangelo
> Masarati

> > BTW, one optimization I intended to implement but haven't
> > the time is to allow:
> > 	struct berval bv = { 0, NULL }
> > 	struct berval *bvp = &bv;
> > 
> > 	rc = dnPretty( NULL, &dn, &bvp );
> > 	rc = dnNormalize( NULL, &dn, &bvp );
> > 
> > That is, allow call to provide, optionally, a
> > pre-allocated struct berval instead of relying
> > on the caller to malloc on up.  Of course, in
> > some cases, the existing behavior is preferred.
> 
> I note that relying on developers (I speak mostly of myself :)
> to supply a NULL pointer if alloc is required or non-NULL pointer
> if it can be safely used is dangerous: no more than five minutes
> ago I fixed this bug in back-monitor.  I'd rather use a alloc/use
> flag in an ancillary function, or radically change the API
> to accept only pre-allocated structs, which wouldn't be a big issue 
> since the big allocation takes place for the bv_val, not for the 
> struct berval.

Well, I guess my last commit counts as a radical change to the API.
Anything that lets you avoid a malloc is a Good Thing. In this case, I've
changed the filter/syntax/indexer structures to embed the struct berval
in their parent structure, instead of using a struct berval pointer.
This cuts malloc calls almost in half, with a corresponding drop in
CPU time. I will be looking thru the code for other places to make
similar changes. (The Attribute->a_vals is a good candidate for gains,
but I left it out this time 'round because that was too much to change
at once.)
  -- Howard