directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@apache.org>
Subject Re: [Studio] Using JDBM for secondary cache
Date Wed, 02 Apr 2008 22:02:50 GMT
On Wed, Apr 2, 2008 at 5:55 PM, Emmanuel Lecharny <elecharny@gmail.com>
wrote:

>
>
> >    I also think that the switch from the old DN/RDN implementation to
> >    the shared-ldap LdapDN/Rdn implementation costs some memory. We
> >    should consider to do some test for performance and memeory
> >    consumtion.
> >
> >
> > Oh that's not good.  We need to cleanup that code anyway so might be
> > good to work in some optimization.
> > Emmanuel had a good idea at some point to build a simple parser for DNs
> > along with a simpler LdapDN class for handling most general cases.  If this
> > parser fails then another corner-case parser continues where the first left
> > off.
> >
> The idea was to consider that a DN is using only ASCII chars. If not,
> throw an exception, and use the standard parser. This can save some cycles,
> that's for sure.
>

That was one of the ideas.  The other was to keep things that complicate the
DN parsing or require additional data structures in the LdapDN out to reduce
additional processing, complexity and footprint.


>
>
> > All these crazy and complicated corner cases like with multi-attribute
> > Rdns and character issues cost more memory.
> >
> No. In no case. It costs time, not memory. We don't store anything but
> Strings.
>

You have some extra storage and references for handling multi-attribute
Rdns.  This costs memory too.


>
>  They can then be handled by this special DN parser with it's resective
> > special LdapDN object that has additional structures for handling these the
> > tracking of these complex DNs.
> >
> > If 99% of the time the simple LDAP DNs are used with smaller footprint,
> > then we can reduce complexity and memory usage, while increasing
> > performance.  This will have an impact for both ApacheDS and Studio.
> >
> Depending on which side we are handling DNs, we may implement different
> optimizations.
>
> * On the client, we don't really care to stroe the UP form.


Right.  The updn and dn need to be separate objects rather than mixing these
concerns.  It's a mess in there right now when mixing all this together.

Alex

Mime
View raw message