[
https://issues.apache.org/jira/browse/AMQ-5825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14581393#comment-14581393
]
Tim Bain commented on AMQ-5825:
-------------------------------
TreeSet will only work if you do what I suggest about keeping the index of the
current "first" element, because we manually reorder the List (which is why it
needs to be a List as currently implemented). So yes, if you do that, TreeSet
would simplify the sorted insertion, but otherwise you have to stick with List.
> Improve performance of Queue.addToConsumerList()
> ------------------------------------------------
>
> Key: AMQ-5825
> URL: https://issues.apache.org/jira/browse/AMQ-5825
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.11.1
> Reporter: Tim Bain
> Priority: Minor
> Labels: performance
>
> In a Users mailing list post
> (http://activemq.2283324.n4.nabble.com/More-ActiveMQ-hotspots-courtesy-of-continuous-profiling-td4697159.html),
> Kevin Burton noticed that Queue.addToConsumerList() was taking 5% of his CPU
> cycles because we're re-sorting after every insert, which is expensive when
> we have lots of consumers. His scenario's a little unique because he uses far
> more destinations (and far more consumers) than most installations, but it
> still highlighted a potential performance improvement.
> I think we can do a sorted insertion (iterate through the list till you find
> the right place based on the comparator, then insert) to skip the re-sort.
> Either we'll be rolling the list or we won't, but either way the list will be
> in sorted order, except that the minimum element might not be the first one.
> So we'd find the minimum element's index (which is O(log N), but can be
> optimized to O(1) for the not-rolling case), then do a sorted insert starting
> at that index and wrapping if necessary.
> Even better, we could implement rolling by just keeping the index of the
> current "first" element, which we would increment each time the list rolled.
> Then instead of looking at element 0, we'd just get that element, which would
> spare us the O(N) operation to roll the list each time we did that. And at
> that point, finding the minimum element's index becomes O(1), not O(log N),
> which is a nice benefit.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
