There is some room for improvement in the encoded metod too...
When we process a search, we write the result to the client. The result
is a plain java object, and we have to encode it as a BER encoded ASN1
message. In order to do that, we compute the size of the buffer we will
need to use to store the message, then we allocate this buffer, and fill it.
As we can see, it's a three step process, but the allocation itself is
just 3% of the encoding time.
The compuatio of the buffer isze is itself the most exepnsive part, and
I believe that it's probably a waste : we don't care to know the exact
size of the needed buffer, as soon as we have a big enough buffer we can
use to store the response. At this point, if we associate a
pre-allocated buffer to the ThreadLocal, we could reuse it over and over
to store the data we will produce during the encoding phase. if the
buffer is too small, then we can catch the exception, create a bigger
buffer, and resume the operation (this is a worse case scenario, which
is not frequent if the bffer is correctly sized to be big enough for
most of the use case).
Haing a 64Kb ByteBuffer pre-allocated and stored in the ThreadLocal is
most certainly the best way to slash the time it takes to encode a message.
We can do what we alredy have done with the Dn parsing : keeping what we
have for when we get an exception because the buffer is too small, and
for the common use case, go on with a simpler encoding where we don't
compute the length of the buffer.
The gain could be intersting!
Note : this is not that simple : to save some CPU, we store the result
of String -> byte conversions done during the computeLength() phase.
Those conversions will have to be done in the simplified method. This
will limit a bit the expected gain. OTOH, we will save us the creation
of many temporary lists we use to store those pre-converted elements.