qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Godfrey" <rob.j.godf...@gmail.com>
Subject Re: Use of AMQShortString in client side code
Date Fri, 14 Sep 2007 06:34:55 GMT
On 13/09/2007, Rajith Attapattu <rajith77@gmail.com> wrote:
> I am wondering why we are using AMQShortString indiscriminately all over
> the
> client side code?
> There is no performance benefit of using AMQShortString (based on the way
> it
> is used) on the client side and is purely used for encoding.


as we have discussed before - there *is* a significant performance benefit
which we have tested and proved previously.  Many short strings are re-used
frequently within the client library, and by using our own type we can
exploit this.  Further, the domain for many parameters in AMQP is *not* a
unicode string, but is tightly defined as upto 255 bytes of data with a
particular encoding.  Java Strings are not the appropriate type to use for
this.  Encoding and decoding Java Strings is expensive, and also prone to
error (i.e. you need to make sure that you *always* use the correct explicit

It makes sense to use it on Broker side as you deal at bytes level and I can
> understand the performance benefit of not having convert back and forth
> into
> a String.

The low level API should be using correct AMQ domains.  High level APIs
(such as JMS) will obviously want to present these parameters as java

On the client side we just merely wrap/unwrap a String using AMQShortString.
> Why can't we do that at the encoding/decoding level for the client side ?

In some cases this may be true, but in others certainly not.  When
converting into JMS Destinations on receipt of a message, for instance, one
never needs to convert to a String... it is *much* faster to simply use the
correct type of AMQShortString/

I really hate typing more than I need to :)

I'm not sure that you laziness is sufficient motivation :-)

-- Rob

> Rajith

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message