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.
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.
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. What we need
is just to _validate_ the DN, keeping the initial String. Each time we
need to parse the DN, we can do it. We can also implement the fail-fast
parser (ASCII DN parser)
* On the server, that's another story. We absolutly need to deal with
the DN/RDN/AttributeTypeAndValue structures, as we have a lot of
controls on them. But the ASCII only parser can be used.
I guess we can quickly write the ASCII parser, and give it a try. If we
gain a lot, then we have to switch to it in the server.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
