RE: binary entry read/write

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

> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
> At 12:26 PM 2001-10-19, Howard Chu wrote:
> >I've just committed some patches for back-bdb that use my new
> encode/decode
> >routines. These use around 1/10th the CPU time of the BER-based
> encoder. In
> >a profile of adding 1205 entries to an empty database, slapd calls
> >ber_memalloc  113172 times. Using the BER encoder it's 412183 times.
> >Performing 4 searches for all of those entries yields 1357115
> memalloc's for
> >BER-based, and only 275025 for my encoder.
>
> How much of the savings is due to caching AttributeDescriptions?

Timewise it's hard to say. slap_bv2ad usage is cut down by about half;
with 103988 calls in the original code, and 43523 calls in the new code and
49962 calls to the caching bdb_str2ad in the new code. Those 103988 calls
to slap_bv2ad account for 176946 out of 485832 calls to ch_malloc.
In the new code, there are only 88108 total calls to ch_malloc, and
slap_bv2ad only accounts for 12273 of those.

Each call to ch_malloc means a call to ber_memalloc, so it's a fair chunk of
the 1.4million calls to ber_memalloc.

These test results are a little flaky because things are not entirely stable
in single-threaded mode. Not sure why, still debugging that. Long strings of
operations tend to get interrupted by SERVER_UNAVAILABLE and I have to
rebind
to continue where I left off...

> >Another aspect of this patch is to cache AttributeDescriptions.
> Currently my
> >changes are in back-bdb/id2entry.c but I think it should be done globally
> >and moved up into slapd itself. I'll look into that some more. Should
> >probably move the bdb_encode/bdb_decode into slapd too, since back-bdb is
> >the only thing that uses the slapd entry_encode/entry_decode
> routines right
> >now.
>
> Yes, this should likely be moved to slapd/entry.c so that
> it could easily be reused in other backends.

Ok. I can look into fitting it into back-ldbm as well if desired. It will
be a bit more invasive due to entry caching; I think any cached entry that
gets modified will have to be discarded, but it should still be a win.
  -- Howard