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 Thu, 20 Sep 2007 11:35:22 GMT
> Perhaps I didn't understand your suggestion. It sounds to me like it is
> the same thing as doing nothing at all. The generated API would use
> String and there would be no copying on encode, however that still
> leaves the overhead of copying and unicode character conversion on
> decode. It is the latter part that using AMQShortString or the
> CharSequence interface can avoid.

OK... Firstly, I think the decision in AMQP 0-10 to make all shortstr's be
a valid UTF-8 string is a mistake, but we can re-visit that over at AMQP :-)

Secondly, the advantages for me of not using String are

i) In the decode we don't need to make a copy into a String object with the
expensive conversion routine it has
ii) In the encode case the encoding for a common string value needs only to
happen once.  Obviously at some point there is still likely to be a copy.

Testing has shown that converting String objects to and from bytes is very
expensive.  In 0-8/0-9 no multibyte encoding was specified for shortstr's
and it was essentially assumed that they consisted of single-byte

The decision that was slipped into 0-10 that shortstr's should be
representations of a particular multi-byte encoding is (I think) a mistake.
It would seem to require a degree of validation on shortstr's that I do not
think is appropriate.  My main issue with shortstr is its name.  It should
instead have been called short-octet-sequence.  The fact that is can be used
to represent encoded data that corresponds to human readable alphabets is
not intrinsic to its use in AMQP I think.

-- Rob

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