qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Schloming <rafa...@redhat.com>
Subject Re: Use of AMQShortString in client side code
Date Tue, 18 Sep 2007 23:05:21 GMT
Robert Godfrey wrote:
> 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.
> 
> 
> 
> Rajith,
> 
> as we have discussed before - there *is* a significant performance benefit
> which we have tested and proved previously.

Can you point me to the previous discussion? I'd like to learn more 
about the original issue.

   Many short strings are re-used
> frequently within the client library, and by using our own type we can
> exploit this.

Unless we're excessively copying them I don't see how this matters. For 
both an AMQShortString and a String we should just be passing around 
pointers when they are reused.

   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
> encoding).

Despite the name AMQShortString, I don't think the AMQShortString class 
actually represents the AMQP type short-string, for example there is no 
length limit for an AMQShortString. It's really just a generic 
implementation of CharSequence that is optimized specifically for rapid 
decoding from a ByteBuffer. From a domain restriction perspective, using 
an ordinary String is just as correct.

> 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
> Strings.
> 
> 
> 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/

Unfortunately using AMQShortString imposes additional overhead whenever 
we need to en/decode to/from an ordinary String. It basically requires 
an additional copy when compared with directly encoding/decoding to/from 
  a String. As the common case on the client side is dealing with 
Strings, I'm not at all convinced that ubiquitous use of AMQShortString 
is a net win for the client.

I believe what would be optimal is to use the CharSequence interface 
everywhere. This way String values passed to us by an application could 
be directly passed all the way down the stack and encoded directly onto 
the wire without an additional copy, and incoming data could be 
efficiently decoded into a private impl of CharSequence that could be 
converted to a String on demand.

--Rafael

Mime
View raw message