On Wed, Apr 2, 2008 at 5:55 PM, Emmanuel Lecharny <email@example.com> wrote:
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.
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.
No. In no case. It costs time, not memory. We don't store anything but Strings.
All these crazy and complicated corner cases like with multi-attribute Rdns and character issues cost more memory.
Depending on which side we are handling DNs, we may implement different optimizations.
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.
* On the client, we don't really care to stroe the UP form.