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

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.