[jira] Assigned: (QPID-320) [Performance] Improve performance by remembering protocol version

["Rob Godfrey (JIRA)" <qp...@incubator.apache.org>]

     [ https://issues.apache.org/jira/browse/QPID-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rob Godfrey reassigned QPID-320:
--------------------------------

    Assignee: Rob Godfrey

> [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
>         Assigned To: Rob Godfrey
>            Priority: Minor
>             Fix For: M2
>
>         Attachments: QPID-320.patch
>
>
> 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.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.