[
https://issues.apache.org/jira/browse/DIRAPI-322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16626795#comment-16626795
]
Emmanuel Lecharny commented on DIRAPI-322:
------------------------------------------
I have ran a little experiment on the Kerberos {{Ticket}} class: encoding it
using a {{ThreadLocal}} storage, and starting from the bottom is something
around 3.5 times faster...
> Use a TLS buffer to encode requests and responses
> -------------------------------------------------
>
> Key: DIRAPI-322
> URL: https://issues.apache.org/jira/browse/DIRAPI-322
> Project: Directory Client API
> Issue Type: Improvement
> Affects Versions: 2.0.0.AM3
> Reporter: Emmanuel Lecharny
> Priority: Major
> Fix For: 2.0.0
>
>
> The way we encode messages is a bit complex. We try not to allocate many
> buffers, but instead pre-compute the needed size, then allocate the buffer,
> and ultimately store the data.
> It might be interesting to pre-allocate a buffer that is stored in the Thread
> Local Storage, big enough to store all the message, most of the time (like, a
> 4Kb buffer). As every encoding will be done in one single thread up to
> completion, this should never be problematic.
> Another improvement, to avoid storing temporary information (like the bytes'
> length or the byte[] for Strings) would be to encode the messages by the end:
> Messages are TLV constructs, where the L gives some information about the V
> part. Usually, we know about the L when the V has been computed. If we start
> by flushing the V into the buffer, from the end, we can append the L before
> it, and so on. When done, we simply have to copy the whole data into the
> right sized buffer.
> That would save a hell lot of allocations, thus GC cycles.
> If the TLS buffer is not big enough, we simply compute the needed size, and
> encode the message the standard way.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
