On Mon, May 5, 2014 at 5:51 PM, Clebert Suconic <csuco...@redhat.com> wrote:
> I have some ideas as well:
> - Calculating size prior to sending:
> - We could write zeroes, write to the buffer... come back to the previous
> position.. write the size instead of calculating it.
Yeah, this is what I've done before. The only tricky thing here is figuring
out how much space to reserve for the size. In order to minimize the size
of the encoded data, it's better to use an encoding with a 1 byte size when
you can, but of course you don't know in advance if the size of the encoded
data will fit within a single byte.
> I have read this code a lot.. and I wouldn't rewrite the code.. just
> optimize these cases... I wouldn't optimize it for every possible case
> TBH.. just on message Delivery and Settling unless you want to also
> optimize other cases for use cases that I'm not aware at the moment.
I think the ability to access key data without doing a full decode is
likely to be useful at some point. I should also say that I think the
actual codec interface is not terribly useful/friendly right now for end
users. I don't particularly mind whether we iterate or replace the current
implementation, but I do think we need a solid idea of the end goal. To
that end I've put together a mock up of a few different strategies that
I've posted in another thread.
> other things that could boost performance based on the micro benchmark I
> - Using Integer, Long.. etc..inside of UnsignedInt, UnsignedLong would
> give you a good boost in performance. The JDK is already optimized to box
> these types... while UnsignedInt, UnsignedLong.. etc.. its not well
I haven't noticed much of a difference between Integer and UnsignedInteger
in any of the profiling I've done, but using the unboxed variants would
definitely make a difference.
> - Reusing buffers.. maybe adding a framework where we could reuse
> buffers.. or delegate into other frameworks (e.g. Netty).
Yeah, we should look at this in the context of copying as well.