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 Fri, 14 Sep 2007 14:43:45 GMT
Hello Robert,

On 9/14/07, Robert Godfrey <rob.j.godfrey@gmail.com> 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.


I agree and understand the performance benifit here and I am not opposed to
the use of  AMQShortString where it makes sense.
However I am opposed to the **indiscriminate** use of AMQShortString inside
the client library.

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


I understand that encoding/decoding to java String is expensive.
So we only gain that benefit if we hang around to the AMQShortString in
bytes without doing any encoding into String.
Now that is a justifiable reason to pass the data in AMQShortString format
around. Ex. the Destination use case you mentioned.
If we are eventually going to use it as a String we could easily do the
conversion once and pass it as a java String.
Since u have to do the conversion once, it doesn't matter where u do it.

I also see frequent use of the asString() method especially in log messages.
Each time u call this, you are doing the String encoding again.
One optimisation is once we create the String we can hang on to it and
return it inside the asString().

On the same token, when we create AMQShortStrings out of Java Strings we can
do it at the lower layers as you have alluded to in your reply.
We need to do the conversion once, and it doesn't matter which layer you do
it.
This will free the upper layers from having to use AMQShortString unless it
is necessary.

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.


Exactly my point. Appologies if I didn't communicate this properly.

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/


Again, I am only talking about the cases where you say it is true.

I really hate typing more than I need to :)
>
>
> I'm not sure that you laziness is sufficient motivation :-)
>
> -- Rob
>
> Regards,
> >
> > Rajith
> >
>

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