>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. Rajith > > On 13/09/2007, Rajith Attapattu <[EMAIL PROTECTED]> 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 >
