-1

Java 7 offers a wide range of different implementations of concurrent queues, namely:

java.util.concurrent.ArrayBlockingQueue<E>
java.util.concurrent.ConcurrentLinkedQueue<E>
java.util.concurrent.LinkedBlockingDeque<E>
java.util.concurrent.LinkedBlockingQueue<E>

Has anyone found any performance characteristics i.e. which one of those seem to be the fastest? I want to use one of the implementations for performance-critical section of my code.

Jason C
  • 38,729
  • 14
  • 126
  • 182
Bober02
  • 15,034
  • 31
  • 92
  • 178
  • 7
    [If you have two horses and you want to know which of the two is the faster then race your horses.](http://ericlippert.com/2012/12/17/performance-rant/) – dcastro Mar 06 '14 at 16:30
  • True indeed :) maybe I will run some performance characteristics and post them back. I was being lazy and was wondering whether anyone has done this already – Bober02 Mar 06 '14 at 16:31
  • My guess would go to `LinkedBlockingDeque`, since it uses the newer `Deque` interface. – Alexis Leclerc Mar 06 '14 at 16:36
  • You might want to take a look at [this](http://stackoverflow.com/questions/1426754/linkedblockingqueue-vs-concurrentlinkedqueue) and [this](http://stackoverflow.com/questions/1301691/java-queue-implementations-which-one)! – Alexis Leclerc Mar 06 '14 at 16:38
  • @AlexisLeclerc I am not sure how the fact that a given container interface is implemented is correlated with performance characteristics of the implementation. – Jason C Mar 06 '14 at 16:40
  • @JasonC As far as I know, `Deque` implementations in Java 6 were introduced to optimize some legacy `Collection` classes (`Stack` being the top best example). I'm just guessing that the `LinkedBlockingDeque` implementation of the `Deque` interface might benefit from the same treatment. – Alexis Leclerc Mar 06 '14 at 16:56
  • 2
    @AlexisLeclerc Don't guess. *Especially* don't guess when an asker is looking for advice that they will presumably take to heart. There's not enough information anyways; e.g. if the throughput is high and performance is CPU-bound, amortized GC characteristics when disposing of linked nodes could make all of the linked-whatevers inappropriate. Or not. Who knows? – Jason C Mar 06 '14 at 17:02
  • @JasonC I was only suggesting a potential solution route, and I agree with you that it can't be validated without the appropriated tests and context. I should have made it more explicit in my comment though! – Alexis Leclerc Mar 06 '14 at 18:42
  • Please read the JavaDocs for these classes. They describe the various situations well under which each class should be used for optimal performance. – TwoThe Mar 07 '14 at 13:42
  • I did, never found any information like that, would you mind pointing to specific excerpts discussing those differences/use-cases? – Bober02 Mar 07 '14 at 14:03

1 Answers1

3

There's no possible way to say which is the "fastest". That question doesn't make much sense. Fastest for what? You'd have to provide at least some amount of requirements. Garbage collection will have an effect. Caching behavior comes into play too and depends on data access patterns.

After determining that your performance requirements are not being met, and concretely identifying the container operations as a bottleneck via proper profiling and benchmarking, it is up to you to test and benchmark your own code in your own specific situations.

The concurrent collections generally exhibit the same high level performance characteristics as their vanilla counterparts.

Jason C
  • 38,729
  • 14
  • 126
  • 182