qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rajith Attapattu" <rajit...@gmail.com>
Subject Re: Use of AMQShortString in client side code
Date Tue, 18 Sep 2007 23:17:31 GMT
>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.

It is exactly my point.
Also as I mentioned we sometimes do the asString() method in logging etc
which does the String encoding every time.
Using Strings or CharSequence is fine.


> > 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

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