Oops, I see it is in already and not that bad. sorry for the last mail.
Carl.
Carl Trieloff wrote:
Robert,
What is the extent of this change? I am thinking it might be good to
back merge the trunk to the branch before
this comes in if it is large. If it is going to be large - when do you
expect that you will be doing it so we can
try get a backmerge from trunk to branch done first.
Carl.
Rob Godfrey (JIRA) wrote:
[Performance] Improve performance by remembering protocol version
-----------------------------------------------------------------
Key: QPID-320
URL: https://issues.apache.org/jira/browse/QPID-320
Project: Qpid
Issue Type: Improvement
Components: Java Broker, Java Common
Reporter: Rob Godfrey
Priority: Minor
Currently all methods are looked up using the protocol version every
time they are received. However once the version is negotiated, the
protocol version for a session cannot change.
Therefore we can attach a version specific method registry to the
session which does not need to look up the methods by protocol
version only by method / class id.
Other performance tweaks included in the soon to follow patch:
1) Cache low numbered channels in array
Currently channels are always looked up in a hash map indexed by an
int. In most cases, only low numbered channels will be used, so we
can use an array to store these and do a lookup here, instead of
incurring the cost of auto-boxing and then hashMap lookup. Given
that this is called at least once (and often more times) on each
message received, the small saving is worthwhile.
2) Reducing autoboxing around messageIds
messageIds are longs, however they are most often used as the keys to
Maps, causing a great deal of boxing/unboxing. To reduce unnecessary
object creation, pass around the Long object messageId rather than
the primitive.
3) Keep track of queue depth
Queue depth is currently calculated by iterating over the messages
and summing their size. This is done at every message add. Instead,
simply keep a running tally of message size.
4) Use singleton / singletonList where we know there will only be one
element
5) Use EnumMap where key is a enum.
